Recursos compartidos en red: permisos y seguridad

Compartir una carpeta dentro de una red parece una operación sencilla: seleccionamos un directorio, activamos una opción y facilitamos una ruta a los usuarios. Sin embargo, publicar el recurso solo es el principio. La parte realmente importante consiste en decidir quién puede acceder, qué operaciones puede realizar, cómo se protege la información y qué pruebas permiten confirmar que la configuración funciona.

Los recursos compartidos en red permiten centralizar documentos, trabajar de forma colaborativa, utilizar impresoras comunes y administrar los datos desde un punto controlado. También facilitan la aplicación de permisos, copias de seguridad, cuotas, auditorías y procedimientos de recuperación. El problema es que una configuración incorrecta puede exponer información confidencial, provocar pérdidas de datos o facilitar que un incidente de seguridad afecte a numerosos archivos.

En mi experiencia impartiendo Sistemas Operativos en Red y Seguridad Informática en Formación Profesional, una de las confusiones más frecuentes aparece cuando se considera que “compartir” y “proteger” son la misma tarea. Un recurso puede estar perfectamente publicado y, aun así, tener unos permisos mal diseñados. También puede ocurrir lo contrario: los permisos del sistema de archivos parecen correctos, pero una restricción adicional impide el acceso desde otro equipo. Mi trayectoria combina ingeniería de software, consultoría tecnológica y docencia, lo que me lleva a abordar este tipo de configuraciones desde una perspectiva estructurada, práctica y fácil de comprobar.

En esta guía veremos cómo funcionan los recursos compartidos en red en Windows y GNU/Linux, qué diferencias existen entre SMB, NTFS, NFS y las ACL, cómo deben planificarse los permisos y qué medidas de seguridad conviene aplicar. También veremos cómo auditar los accesos y cómo actuar cuando un usuario recibe un mensaje de acceso denegado.

Qué son los recursos compartidos en red

Un recurso compartido es un elemento de un sistema que se publica para que pueda utilizarse desde otros equipos. Los ejemplos más habituales son las carpetas, los archivos y las impresoras, aunque también pueden compartirse dispositivos, repositorios, volúmenes de almacenamiento o determinados servicios.

La principal ventaja de los recursos compartidos en red es la centralización. En lugar de mantener múltiples copias de un documento en diferentes ordenadores, los usuarios trabajan sobre una ubicación común. Esto reduce las versiones contradictorias, simplifica las copias de seguridad y permite administrar los permisos desde un punto definido.

En una organización podemos encontrar, por ejemplo:

Una carpeta de documentación común.
Un directorio exclusivo para la dirección.
Un espacio de trabajo para cada departamento.
Una carpeta donde el alumnado deposita sus entregas.
Un repositorio de programas y plantillas.
Una impresora utilizada por varias aulas o despachos.
Un servidor de archivos o un dispositivo NAS.

Compartir estos recursos también reduce costes y facilita el mantenimiento. Una impresora de red puede utilizarse desde diferentes equipos, mientras que un servidor de archivos permite aplicar políticas comunes de almacenamiento, seguridad y conservación.

Sin embargo, la centralización también concentra el riesgo. Cuando una cuenta obtiene permiso de modificación sobre miles de documentos, puede modificarlos, sobrescribirlos o eliminarlos. Esto puede suceder debido a un error humano, una aplicación defectuosa o una infección de ransomware. Por eso, la disponibilidad de un recurso debe ir acompañada de permisos adecuados, copias de seguridad y capacidad de recuperación.

Acceso local y acceso remoto

El acceso local se produce directamente sobre el sistema de archivos del servidor. Por ejemplo:

D:\Datos\Profesorado\Programaciones

El acceso remoto se realiza desde otro equipo mediante una ruta de red:

\\SRV-FICHEROS\Profesorado\Programaciones

Esta diferencia es importante porque el acceso remoto suele incorporar una capa adicional de permisos. En Windows, un acceso local puede depender únicamente de los permisos NTFS, mientras que el acceso mediante SMB combina los permisos del recurso compartido con los permisos del sistema de archivos.

Por tanto, una persona puede abrir una carpeta localmente en el servidor y recibir una denegación al utilizar la ruta de red. También puede suceder que el usuario tenga permisos suficientes en el recurso compartido, pero no en la carpeta física.

Protocolos utilizados para compartir recursos

Los principales protocolos que aparecen en entornos Windows y Linux son los siguientes:

Protocolo	Entorno habitual	Utilidad
SMB	Windows y sistemas compatibles	Compartir archivos, carpetas e impresoras
NFS	GNU/Linux y Unix	Montar directorios remotos dentro del sistema local
IPP	Sistemas de impresión	Publicar y administrar impresoras en red
CIFS	Sistemas antiguos	Denominación asociada a implementaciones antiguas de SMB

CIFS no debe utilizarse como sinónimo general de las versiones actuales de SMB. De la misma manera, SMB1 es una tecnología antigua que no debe activarse salvo que exista una necesidad excepcional, temporal y correctamente aislada.

Cómo se controla el acceso a un recurso compartido

Para administrar correctamente los recursos compartidos en red debemos diferenciar varias fases. El usuario declara su identidad, el sistema comprueba que realmente es quien dice ser y, a continuación, decide qué acciones puede realizar.

El proceso general puede representarse así:

Identificación
    ↓
Autenticación
    ↓
Construcción de la identidad de seguridad
    ↓
Evaluación de permisos
    ↓
Acceso o denegación
    ↓
Auditoría

Identificación

La identificación consiste en indicar quién pretende acceder. Normalmente se realiza mediante un nombre de usuario, una dirección de correo o alguna otra identidad reconocida por el sistema.

Indicar un nombre no demuestra que la persona sea su propietaria. Por eso, la identificación debe acompañarse de un mecanismo de autenticación.

Autenticación

La autenticación permite comprobar la identidad. Puede realizarse mediante:

Una contraseña.
Un certificado.
Una clave criptográfica.
Una tarjeta.
Un código temporal.
Un factor biométrico.
Una combinación de varios factores.

La autenticación responde a la pregunta: “¿Eres realmente la persona que afirmas ser?”.

Autorización

Una vez autenticado el usuario, el sistema comprueba qué operaciones puede realizar. La autorización responde a preguntas como:

¿Puede ver esta carpeta?
¿Puede abrir los archivos?
¿Puede crear documentos?
¿Puede modificar o eliminar el contenido?
¿Puede cambiar los permisos?
¿Puede administrar la impresora?

Autenticarse correctamente no implica disponer de acceso a todos los recursos. Una cuenta puede ser válida y, sin embargo, carecer de permiso sobre una carpeta determinada.

Auditoría

La auditoría registra acciones y resultados. Su objetivo es poder responder posteriormente:

Quién intentó acceder.
A qué recurso.
Desde qué equipo.
En qué momento.
Qué operación realizó.
Si la acción fue permitida o denegada.

No todos los accesos deben registrarse indiscriminadamente. Una auditoría excesiva puede generar tal cantidad de eventos que resulte difícil encontrar la información importante. Conviene definir qué recursos son sensibles y qué operaciones necesitan seguimiento.

El token de acceso en Windows

Cuando un usuario inicia sesión en Windows, el sistema genera un token de acceso. Este token contiene el identificador de seguridad del usuario, los identificadores de sus grupos, sus privilegios y determinadas restricciones.

Al acceder a una carpeta, Windows compara ese token con la lista de control de acceso del objeto. De ahí se deriva una recomendación fundamental: los permisos deben asignarse preferentemente a grupos, no directamente a usuarios individuales.

Cuando se cambia la pertenencia de una persona a un grupo, puede ser necesario cerrar y volver a iniciar sesión para que el sistema construya un token actualizado. Por eso, en ocasiones un permiso parece estar correctamente concedido, pero todavía no se aplica a la sesión actual.

UID, GID y grupos en Linux

GNU/Linux utiliza identificadores numéricos para representar usuarios y grupos:

UID: identificador del usuario.
GID: identificador del grupo principal.
Grupos suplementarios: otros grupos a los que pertenece el usuario.

Podemos consultarlos con:

id ana

Una salida posible sería:

uid=1050(ana) gid=1100(profesorado) grupos=1100(profesorado),1150(proyecto_web)

El servidor compara estos identificadores con el propietario, el grupo y las ACL del archivo o directorio. En NFS, esta correspondencia resulta especialmente importante porque un UID diferente en el cliente y en el servidor puede hacer que el sistema aplique los permisos a la identidad equivocada.

Qué son las ACL y las ACE

Una lista de control de acceso, conocida como ACL, especifica las identidades que pueden realizar determinadas acciones sobre un recurso. Cada regla individual almacenada dentro de la ACL recibe el nombre de ACE.

Una ACE suele contener cuatro elementos:

Elemento	Ejemplo	Función
Principal de seguridad	Usuario Ana o grupo Profesorado	Identidad afectada
Tipo	Permitir o denegar	Efecto de la entrada
Permisos	Leer, escribir o modificar	Operaciones controladas
Herencia	Carpeta, subcarpetas y archivos	Ámbito de aplicación

Esta estructura permite crear configuraciones bastante precisas. Podemos conceder lectura a un grupo, modificación a otro y control total únicamente al personal técnico.

La flexibilidad, sin embargo, también puede convertirse en un problema. Una ACL con decenas de usuarios individuales, excepciones, entradas denegadas y herencias interrumpidas resulta difícil de comprender. Con el paso del tiempo, nadie recuerda por qué se creó cada regla y cualquier modificación puede producir efectos inesperados.

Como ingeniero de software, estoy acostumbrado a dividir los problemas en partes y buscar soluciones que sigan siendo mantenibles cuando crecen. Mi experiencia profesional en desarrollo y mantenimiento de soluciones me ha enseñado que una configuración técnicamente válida no siempre es una buena configuración. En los permisos ocurre exactamente lo mismo: si solo la comprende quien la creó, probablemente terminará generando incidencias.

La mejor estrategia suele ser mantener una estructura predecible:

Agrupar a los usuarios según su función.
Crear grupos asociados a los permisos del recurso.
Relacionar los grupos funcionales con los grupos del recurso.
Asignar los permisos a estos últimos grupos.
Documentar las excepciones inevitables.
Revisar periódicamente la configuración.

Esto permite que un cambio de puesto se resuelva modificando la pertenencia a grupos, sin editar manualmente las ACL de numerosas carpetas.

Diferencias entre permisos, derechos y privilegios

Aunque a veces se utilizan como términos intercambiables, los permisos, los derechos y los privilegios representan conceptos distintos.

Permisos sobre objetos

Un permiso define qué puede hacer una identidad sobre un objeto concreto. Por ejemplo:

Leer una carpeta.
Modificar un archivo.
Crear un documento.
Eliminar un directorio.
Enviar trabajos a una impresora.
Administrar una cola de impresión.
Cambiar la ACL de un recurso.

El permiso se encuentra asociado al objeto. Por eso, una persona puede tener permiso para modificar una carpeta y únicamente lectura sobre otra.

Derechos de usuario

Un derecho autoriza a una identidad a ejecutar una operación del sistema que no tiene por qué estar vinculada a un archivo concreto.

Algunos ejemplos en Windows son:

Iniciar sesión localmente.
Acceder al equipo desde la red.
Realizar copias de seguridad.
Restaurar archivos y directorios.
Apagar el sistema.
Tomar posesión de archivos.
Iniciar sesión como servicio.

Estos derechos deben concederse con precaución. El derecho a realizar copias de seguridad, por ejemplo, puede permitir leer determinados archivos ignorando algunos permisos ordinarios. El derecho a tomar posesión puede utilizarse para asumir la propiedad de un objeto y cambiar después su ACL.

Privilegios

Los privilegios son capacidades especiales asociadas a la identidad o al proceso. En la práctica, algunos derechos de usuario de Windows actúan como privilegios técnicos.

El detalle terminológico puede variar según el sistema, pero la diferencia importante es la siguiente:

Concepto	Pregunta a la que responde
Permiso	¿Qué puede hacer sobre este objeto?
Derecho	¿Qué operación del sistema puede ejecutar?
Rol	¿Qué función desempeña?
Grupo	¿Cómo agrupamos identidades con necesidades similares?

Principio de mínimo privilegio

El principio de mínimo privilegio establece que cada usuario debe disponer únicamente de las capacidades imprescindibles, durante el tiempo necesario y sobre el ámbito correcto.

No debemos conceder control total cuando una persona solo necesita leer documentos. Tampoco deberíamos facilitar permiso de modificación sobre una carpeta completa cuando únicamente necesita subir archivos a un subdirectorio concreto.

Modificar no significa simplemente “editar”. En muchos sistemas, el permiso de modificación también permite sobrescribir y eliminar. Esta cuestión resulta especialmente importante frente al ransomware: cualquier malware ejecutado con las credenciales del usuario puede actuar sobre los archivos que ese usuario sea capaz de modificar.

El mínimo privilegio no es una barrera infalible, pero reduce el alcance potencial de los errores y los incidentes.

Cómo planificar correctamente los recursos compartidos en red

Una buena configuración comienza antes de abrir el asistente de Windows Server o editar /etc/exports en Linux.

Durante mi etapa en consultoría tecnológica aprendí la importancia de escuchar y comprender una necesidad antes de hablar de herramientas. Esa misma idea se aplica a los recursos compartidos en red: antes de elegir opciones técnicas debemos saber quién utilizará el recurso, para qué lo necesita y qué consecuencias tendría un acceso indebido. Mi experiencia en consultoría incluyó gestión de peticiones, documentación, mejora de procesos y relación con clientes, tareas que obligan a convertir necesidades generales en requisitos concretos.

Inventario previo

Antes de publicar una carpeta o una impresora conviene documentar:

Dato	Pregunta que debemos responder
Propietario funcional	¿Quién decide qué personas pueden acceder?
Administrador técnico	¿Quién mantiene la configuración?
Usuarios	¿Qué grupos necesitan el recurso?
Operaciones	¿Necesitan leer, crear, modificar o administrar?
Confidencialidad	¿Contiene información sensible?
Disponibilidad	¿Qué ocurriría si el recurso dejara de funcionar?
Conservación	¿Cuánto tiempo deben mantenerse los datos?
Copias	¿Con qué frecuencia se realizan?
Recuperación	¿Se han probado las restauraciones?
Auditoría	¿Qué acciones deben registrarse?
Revisión	¿Cuándo se comprobarán de nuevo los accesos?
Baja	¿Cuándo debe retirarse el recurso?

El propietario funcional no tiene por qué ser el administrador técnico. Un departamento puede decidir quién necesita sus documentos, mientras que el personal de sistemas ejecuta la configuración.

Convenciones de nombres

Los nombres deben ser breves, estables y comprensibles:

Carpeta física: D:\Datos\Departamentos\Profesorado
Recurso compartido: Profesorado
Ruta UNC: \\SRV-FICHEROS\Profesorado

No conviene utilizar el nombre de una persona si el recurso pertenece a un departamento. Tampoco resulta recomendable incluir ubicaciones o fechas que puedan cambiar.

Los grupos de permisos también deberían seguir una nomenclatura coherente:

DL_Profesorado_Lectura
DL_Profesorado_Modificar
DL_Profesorado_Control

La nomenclatura debe permitir que otro administrador comprenda la finalidad del grupo sin abrir su descripción.

Matriz de acceso

Una matriz de acceso representa los recursos en filas y los grupos o roles en columnas. En cada celda se indica el nivel autorizado.

Recurso	Dirección	Profesorado	Alumnado	TI
Común	Modificar	Modificar	Leer	Control total
Dirección	Modificar	Sin acceso	Sin acceso	Control total
Profesorado	Leer	Modificar	Sin acceso	Control total
Entregas	Revisar	Revisar	Crear según diseño	Control total
Software	Leer	Leer	Leer	Modificar

La matriz funciona como especificación. Primero se acuerda el resultado esperado y después se configura el servidor. Así evitamos conceder permisos “de memoria” o improvisar soluciones durante la instalación.

Modelo basado en grupos

En un dominio Windows, el modelo AGDLP separa las cuentas, los grupos funcionales y los grupos asociados al recurso:

Ana
  ↓
GG_Profesorado
  ↓
DL_Profesorado_Modificar
  ↓
Permiso Modificar sobre la carpeta

La cuenta se incorpora a un grupo global que representa su función. Ese grupo se añade a un grupo local de dominio asociado al recurso. Finalmente, los permisos se asignan al grupo local.

Este enfoque mejora la trazabilidad. Si Ana cambia de departamento, modificamos su grupo funcional. No necesitamos localizar todos los recursos sobre los que recibió permisos individualmente.

Cómo compartir carpetas en Windows Server

Windows Server utiliza principalmente SMB para compartir carpetas. La configuración puede realizarse mediante el Explorador de archivos, Administración de equipos, Administrador del servidor, Windows Admin Center o PowerShell.

La herramienta seleccionada no cambia el modelo de seguridad. En todos los casos debemos considerar dos capas:

Permisos del recurso compartido.
Permisos NTFS sobre la carpeta física.

Requisitos previos

Antes de compartir una carpeta debemos comprobar:

Dirección IP y configuración DNS.
Nombre correcto del servidor.
Conectividad desde los clientes.
Carpeta física creada en una ubicación documentada.
Grupos de seguridad preparados.
Sistema de archivos adecuado.
Reglas de firewall limitadas a los perfiles necesarios.
Servicio SMB disponible.
Capacidad de almacenamiento suficiente.
Copias de seguridad planificadas.

También conviene evitar compartir directamente carpetas improvisadas en el escritorio o dentro de perfiles personales. Los datos corporativos deberían almacenarse en volúmenes y estructuras creadas para ese propósito.

Creación mediante el entorno gráfico

El proceso general es:

Crear la carpeta física.
Abrir sus propiedades.
Acceder a la pestaña de uso compartido.
Activar el uso compartido avanzado.
Definir el nombre del recurso.
Configurar los permisos SMB.
Configurar los permisos NTFS.
Aplicar los cambios.
Probar la ruta UNC desde un cliente.
Realizar pruebas con usuarios autorizados y no autorizados.

También podemos utilizar el asistente de Servicios de archivos y almacenamiento de Windows Server. Este asistente permite activar características como el cifrado SMB o la enumeración basada en acceso.

Creación con PowerShell

Un ejemplo de creación podría ser:

New-Item -Path 'D:\Datos\Profesorado' -ItemType Directory

New-SmbShare `
  -Name 'Profesorado' `
  -Path 'D:\Datos\Profesorado' `
  -FullAccess 'CENTRO\DL_Profesorado_Control' `
  -ChangeAccess 'CENTRO\DL_Profesorado_Modificar' `
  -ReadAccess 'CENTRO\DL_Profesorado_Lectura'

Algunos comandos útiles son:

Get-SmbShare
Get-SmbShareAccess
Grant-SmbShareAccess
Revoke-SmbShareAccess
Set-SmbShare
Remove-SmbShare

Remove-SmbShare elimina la publicación, pero no borra necesariamente la carpeta física. Esta diferencia evita confundir la retirada de un recurso compartido con la eliminación de sus datos.

Recursos ocultos

En Windows, un nombre terminado en $ no aparece durante la exploración normal:

\\SRV-FICHEROS\Administracion$

Esto no convierte el recurso en seguro. Si una persona conoce la ruta y dispone de permisos, podrá intentar acceder. Un recurso oculto reduce la visibilidad, pero no sustituye a la autenticación, las ACL, el firewall o la auditoría.

Windows también mantiene recursos administrativos como C$, ADMIN$ e IPC$. Su uso debe quedar reservado a las tareas de administración autorizadas.

Permisos NTFS y acceso efectivo

NTFS permite establecer permisos detallados sobre archivos y carpetas. Estos permisos se aplican tanto al acceso local como al acceso remoto y constituyen la principal capa de protección de los datos en un servidor Windows.

Permisos estándar

Permiso	Capacidades generales
Control total	Leer, escribir, ejecutar, eliminar, cambiar permisos y tomar posesión
Modificar	Leer, escribir, ejecutar y eliminar
Lectura y ejecución	Ver contenido y ejecutar archivos autorizados
Mostrar contenido	Enumerar elementos de una carpeta
Lectura	Consultar datos, atributos y permisos
Escritura	Crear y modificar determinados datos

Control total debe reservarse para quienes realmente necesiten administrar la ACL o la propiedad. La mayoría de los usuarios que trabajan con documentos únicamente necesitan Modificar.

Permisos especiales

Los permisos estándar agrupan capacidades más específicas:

Recorrer carpeta.
Ejecutar archivo.
Listar carpeta.
Leer datos.
Crear archivos.
Crear carpetas.
Anexar datos.
Eliminar.
Eliminar subcarpetas y archivos.
Cambiar permisos.
Tomar posesión.

Estos permisos permiten diseñar escenarios avanzados, como una carpeta de entregas donde el alumnado pueda depositar archivos sin consultar los documentos de otras personas. Sin embargo, las configuraciones especiales deben documentarse y probarse cuidadosamente.

Permitir y denegar

Las entradas Permitir conceden capacidades. Las entradas Denegar bloquean determinadas acciones y normalmente tienen un efecto prioritario cuando afectan a la misma operación.

No obstante, no conviene reducir toda la evaluación a la frase “denegar siempre gana”. La prioridad puede depender de si las entradas son explícitas o heredadas y del ámbito sobre el que se aplican.

Como regla práctica:

Utilizar grupos y permisos permitidos siempre que sea posible.
Reservar las denegaciones para excepciones justificadas.
Evitar grupos con reglas contradictorias.
Revisar el acceso efectivo.
Probar siempre con una cuenta real.

Las denegaciones suelen complicar el diagnóstico. Un usuario puede pertenecer a cinco grupos y recibir una denegación inesperada a través de uno de ellos.

Permisos acumulativos

Dentro de una misma capa, los permisos permitidos suelen acumularse. Si un grupo concede lectura y otro concede escritura, el usuario puede recibir ambas capacidades.

Esto explica por qué no basta con revisar un único grupo. Para conocer el resultado debemos considerar todas las identidades incluidas en el token.

Acceso efectivo

La herramienta Acceso efectivo permite seleccionar una identidad y calcular los permisos resultantes sobre un objeto. Tiene en cuenta:

Usuario.
Grupos.
Entradas explícitas.
Entradas heredadas.
Permisos permitidos.
Denegaciones.
Ámbito de aplicación.

Aun así, el cálculo debe complementarse con una prueba real. Una captura de la ACL demuestra la configuración existente, pero no confirma que la resolución de nombres, las credenciales, los permisos SMB y la sesión del usuario funcionen correctamente.

Cómo se combinan los permisos SMB y NTFS

Esta es una de las cuestiones más importantes al administrar recursos compartidos en red con Windows.

Cuando el usuario accede mediante una ruta UNC o una unidad de red, se evalúan:

Los permisos del recurso SMB.
Los permisos NTFS de la carpeta o el archivo.

El resultado no puede superar lo permitido por ninguna de las dos capas. Por eso suele decirse que se aplica la combinación más restrictiva.

Permiso SMB	Permiso NTFS	Resultado por red
Lectura	Modificar	Lectura
Cambiar	Lectura	Lectura
Control total	Modificar	Modificar
Cambiar	Modificar	Modificar
Control total	Sin acceso	Sin acceso

Supongamos que un usuario recibe Modificar en NTFS, pero solo Lectura en el recurso compartido. Cuando accede mediante la red podrá leer, pero no modificar. Si el administrador revisa únicamente la pestaña Seguridad, podría pensar que el permiso es correcto y no encontrar la causa.

Estrategia de permisos amplios en SMB

Una estrategia habitual consiste en conceder un permiso amplio en el recurso compartido y controlar el detalle mediante NTFS.

Por ejemplo:

SMB: Control total para usuarios autenticados
NTFS: permisos específicos según grupos

La principal ventaja es que la lógica se concentra en una sola ACL. También mantiene un comportamiento más coherente entre el acceso local y el remoto.

La precaución es evidente: si NTFS queda mal configurado, la capa SMB no funcionará como una barrera adicional suficientemente restrictiva.

Estrategia restrictiva en ambas capas

Otra posibilidad consiste en limitar tanto SMB como NTFS.

Esta estrategia añade una segunda barrera y permite aplicar restricciones específicas al acceso remoto. Sin embargo, aumenta la complejidad y puede generar denegaciones difíciles de diagnosticar.

No existe una única estrategia válida para todos los entornos. Lo importante es que la decisión sea coherente, esté documentada y se pruebe.

Acceso local frente a acceso remoto

Forma de acceso	Capas evaluadas
Acceso local en el servidor	NTFS
Ruta UNC	SMB y NTFS
Unidad mapeada	SMB y NTFS
Operaciones administrativas especiales	Permisos y posibles privilegios

Una unidad mapeada no modifica los permisos. Solo proporciona una forma más cómoda de acceder a la ruta UNC:

net use P: \\SRV-FICHEROS\Profesorado /persistent:yes

Si el usuario no puede abrir la ruta original, tampoco podrá hacerlo mediante la unidad asignada.

Herencia, propiedad y movimiento de archivos

La herencia permite que los permisos de una carpeta se propaguen a sus descendientes. Resulta útil porque reduce el trabajo administrativo y mantiene una política uniforme.

D:\Datos
└── Profesorado
    ├── Programaciones
    └── Confidencial

La carpeta Profesorado puede heredar permisos de Datos. A su vez, Programaciones puede heredar los permisos de Profesorado. La carpeta Confidencial, en cambio, puede necesitar una configuración específica.

Entradas explícitas y heredadas

Una entrada explícita se configura directamente sobre el objeto. Una entrada heredada procede de una carpeta superior.

Las entradas explícitas sirven para introducir excepciones. El problema aparece cuando cada subcarpeta contiene reglas particulares y nadie puede determinar qué política se está aplicando.

Antes de desactivar la herencia debemos decidir qué hacer con las entradas existentes:

Convertirlas en permisos explícitos.
Eliminarlas y comenzar una ACL nueva.

La primera opción conserva el resultado actual, pero crea más entradas independientes. La segunda simplifica la ACL, aunque puede provocar una pérdida inmediata de acceso si no se prepara correctamente.

Ámbito de aplicación

Los permisos pueden aplicarse a diferentes ámbitos:

Esta carpeta solamente.
Esta carpeta, subcarpetas y archivos.
Esta carpeta y subcarpetas.
Solo subcarpetas y archivos.
Solo archivos.
Solo subcarpetas.

El ámbito permite diseñar comportamientos precisos. Por ejemplo, podemos conceder a una persona capacidad para crear archivos dentro de una carpeta sin permitirle leer todo su contenido. Estos diseños deben probarse con especial cuidado.

Propietario

El propietario de un objeto suele disponer de una capacidad especial para administrar sus permisos. Tomar posesión no concede automáticamente acceso al contenido, pero permite modificar posteriormente la ACL.

Por esa razón, el derecho a tomar posesión debe considerarse sensible. Una persona que pueda asumir la propiedad de un archivo puede terminar concediéndose permisos sobre él.

Copiar y mover

El comportamiento general en NTFS es:

Operación	Resultado habitual
Copiar a otra carpeta	El nuevo objeto hereda los permisos del destino
Mover dentro del mismo volumen	El objeto conserva normalmente sus permisos
Mover a otro volumen	Se comporta como copia y eliminación

Esta diferencia puede causar sorpresas durante una migración. Antes de trasladar una gran cantidad de datos debemos probar una muestra y revisar:

Permisos.
Propiedad.
Herencia.
Auditoría.
Acceso desde los clientes.

Las herramientas de copia y sus opciones pueden alterar el comportamiento predeterminado, por lo que no conviene confiar únicamente en una regla memorizada.

Cómo compartir directorios en Linux mediante NFS

En una red homogénea GNU/Linux, NFS permite exportar un directorio desde un servidor y montarlo en los clientes como parte de su propio árbol de archivos.

La seguridad no depende únicamente de la línea incluida en /etc/exports. También intervienen:

UID y GID.
Permisos POSIX.
ACL.
Opciones de exportación.
Firewall.
Red autorizada.
Versión de NFS.
Autenticación.
Configuración del cliente.

Permisos POSIX

Cada archivo dispone de permisos para:

Propietario.
Grupo.
Otros.

Las operaciones básicas son lectura, escritura y ejecución.

Permiso	En un archivo	En un directorio
`r`	Leer el contenido	Listar nombres
`w`	Modificar el contenido	Crear, borrar o renombrar
`x`	Ejecutar	Atravesar el directorio

El permiso de escritura sobre un directorio no debe interpretarse exactamente igual que sobre un archivo. Para crear o eliminar elementos normalmente se necesita también ejecución sobre el directorio.

Podemos revisar los permisos con:

ls -ld /srv/profesorado

Una salida posible sería:

drwxrws--- 5 root profesorado 4096 jun 22 10:30 /srv/profesorado

chmod, chown y chgrp

Los principales comandos son:

chown root:profesorado /srv/profesorado
chmod 2770 /srv/profesorado

chown cambia el propietario y, opcionalmente, el grupo.
chgrp cambia el grupo propietario.
chmod modifica los permisos.
El bit setgid en un directorio facilita que los nuevos elementos hereden el grupo del directorio.

La notación 2770 representa:

2: bit setgid.
7: lectura, escritura y ejecución para el propietario.
7: lectura, escritura y ejecución para el grupo.
0: ningún permiso para otros.

Umask

La umask limita los permisos iniciales de los nuevos elementos:

umask 0027

Con esta máscara, los archivos suelen crearse con permisos 640 y los directorios con 750, aunque el resultado también puede depender de la aplicación.

La umask no sustituye a las ACL. Solo interviene en los permisos iniciales.

ACL POSIX

Las ACL permiten conceder permisos a usuarios y grupos adicionales:

setfacl -m g:profesorado:rwx /srv/profesorado
setfacl -m g:direccion:rx /srv/profesorado
setfacl -d -m g:profesorado:rwx /srv/profesorado
getfacl /srv/profesorado

La opción -d permite establecer ACL predeterminadas para los nuevos elementos.

Es importante revisar la máscara de la ACL, ya que puede limitar los permisos efectivos. Una entrada puede indicar rwx, pero el resultado real ser menor debido a esa máscara.

Publicación y montaje de un recurso NFS

Una exportación básica podría ser:

/srv/profesorado 192.168.50.0/24(rw,sync,root_squash,no_subtree_check)

Las opciones significan:

rw: permite lectura y escritura.
sync: confirma las operaciones después de escribir los datos de forma estable.
root_squash: evita que el usuario root del cliente actúe como root en el recurso.
no_subtree_check: evita determinadas comprobaciones sobre subdirectorios.

Después de modificar las exportaciones podemos ejecutar:

exportfs -ra
exportfs -v

Desde un cliente podemos consultar los recursos:

showmount -e servidor-nfs

Y montar el directorio:

mount -t nfs srv-nfs:/srv/profesorado /mnt/profesorado

Después conviene verificarlo:

findmnt /mnt/profesorado
touch /mnt/profesorado/prueba.txt

Crear un archivo de prueba no es suficiente. También debemos comprobar su propietario, grupo, permisos y visibilidad desde otros usuarios.

Correspondencia de identidades

En configuraciones clásicas de NFS, el UID y el GID deben representar a las mismas identidades en el cliente y el servidor.

Si ana utiliza el UID 1050 en el servidor y el UID 2050 en el cliente, el sistema puede interpretar sus archivos como pertenecientes a otra persona o mostrar únicamente el identificador numérico.

Un servicio centralizado de identidades reduce este riesgo. Si no existe, debemos coordinar cuidadosamente la creación de usuarios y grupos.

Diagnóstico de permisos en Linux

Algunos comandos especialmente útiles son:

id usuario
namei -l /srv/profesorado/curso/documento.odt
getfacl /srv/profesorado/curso/documento.odt
mount | grep nfs
exportfs -v
journalctl -u nfs-server

namei -l resulta muy útil porque muestra los permisos de cada componente de la ruta. El usuario puede tener acceso al archivo final y, sin embargo, carecer de ejecución sobre uno de los directorios intermedios.

Impresoras compartidas en Windows y Linux

Los recursos compartidos en red no se limitan a carpetas y archivos. Las impresoras también pueden centralizarse mediante un servidor que administre las colas, los controladores, los permisos y el seguimiento de los trabajos.

Un sistema de impresión suele incluir:

Elemento	Función
Dispositivo físico	Realiza la impresión
Puerto	Representa la conexión con el dispositivo
Controlador	Convierte el trabajo al formato adecuado
Cola	Organiza los trabajos pendientes
Spooler	Gestiona los trabajos
Impresora lógica	Reúne configuración, puerto, permisos y preferencias

Impresoras compartidas en Windows

El proceso general consiste en:

Instalar los servicios de impresión necesarios.
Crear o seleccionar el puerto.
Instalar un controlador compatible y confiable.
Crear la impresora lógica.
Imprimir una página de prueba.
Activar el uso compartido.
Configurar los permisos.
Conectar desde un cliente.
Comprobar la cola.

Los principales permisos son:

Permiso	Capacidades
Imprimir	Enviar documentos y administrar los trabajos propios
Administrar documentos	Gestionar trabajos de otros usuarios
Administrar esta impresora	Cambiar configuración y permisos

No deberíamos conceder Administrar documentos a todos los usuarios. Ese permiso permitiría cancelar, pausar o reiniciar los trabajos enviados por otras personas.

PowerShell también permite crear impresoras:

Add-PrinterPort `
  -Name 'IP_192.168.50.40' `
  -PrinterHostAddress '192.168.50.40'

Add-Printer `
  -Name 'IMP-ADMIN' `
  -DriverName 'Controlador del fabricante' `
  -PortName 'IP_192.168.50.40' `
  -Shared `
  -ShareName 'IMP-ADMIN'

El nombre exacto del controlador debe consultarse con Get-PrinterDriver. Nunca deberíamos instalar en un servidor paquetes obtenidos de fuentes dudosas.

CUPS en GNU/Linux

CUPS administra impresoras y colas en GNU/Linux y utiliza habitualmente IPP.

Algunos comandos frecuentes son:

lpstat -t
lpadmin -p imp_admin -E \
  -v ipp://192.168.50.40/ipp/print \
  -m everywhere
lpoptions -d imp_admin
lp documento.pdf
lpq -P imp_admin
cancel trabajo-id

La administración web de CUPS no debe exponerse a toda la red sin autenticación y cifrado. También conviene limitar las interfaces de escucha y los clientes autorizados.

Antes de reinstalar el servicio o el controlador debemos revisar:

systemctl status cups
journalctl -u cups
lpstat -p -d
ippfind
cupsctl

Con frecuencia, el problema se encuentra en la URI, la cola, los permisos, el formato del trabajo o la conectividad con la impresora.

Seguridad de los recursos compartidos en red

La seguridad debe aplicarse por capas. Ningún control individual resulta suficiente.

Una configuración segura combina:

Identidades individuales.
Grupos.
Mínimo privilegio.
Protocolos actuales.
Firewall.
Cifrado cuando sea necesario.
Actualizaciones.
Copias de seguridad.
Auditoría.
Monitorización.
Revisión de permisos.
Procedimientos de recuperación.

Medidas de seguridad para SMB

Las medidas principales son:

Deshabilitar SMB1.
Limitar SMB a las redes autorizadas.
Aplicar firma SMB cuando sea necesario.
Utilizar cifrado SMB para información sensible.
Bloquear el acceso de invitado si no resulta imprescindible.
Mantener servidor y clientes actualizados.
Utilizar enumeración basada en acceso cuando mejore la experiencia.
Registrar los accesos relevantes.
Separar las cuentas administrativas.
Revisar periódicamente las ACL.

La enumeración basada en acceso impide que el usuario vea carpetas para las que carece de permiso de listado. Mejora la claridad y reduce la exposición visual, pero no sustituye a los permisos. Ocultar un elemento no constituye una barrera de seguridad.

Medidas de seguridad para NFS

En NFS conviene:

Limitar la exportación a hosts o redes concretas.
Utilizar root_squash.
Evitar exportaciones de escritura general.
Mantener coherencia de UID y GID.
Preferir versiones modernas del protocolo.
Utilizar mecanismos de autenticación robustos cuando estén disponibles.
Proteger el tráfico mediante una red confiable, segmentación o cifrado.
Revisar permisos POSIX y ACL.
Mantener registros del servicio.

Una exportación configurada para toda la red y con escritura indiscriminada puede convertirse en un punto crítico de seguridad.

Protección frente al ransomware

El ransomware no necesita obtener permisos administrativos para causar daños importantes. Si un usuario puede modificar una carpeta compartida, un proceso ejecutado con sus credenciales puede cifrar, sobrescribir o eliminar esos mismos archivos.

Por eso, la protección no puede depender únicamente del antivirus. Debemos aplicar:

Mínimo privilegio.
Segmentación.
Copias desconectadas o inmutables.
Versiones anteriores o instantáneas.
Detección de comportamientos anómalos.
Actualizaciones.
Separación de cuentas.
Plan de respuesta.
Restauraciones probadas.

Las instantáneas son útiles, pero no deberían considerarse la única copia. Un atacante puede intentar borrarlas o cifrar el sistema que las almacena.

Copias y recuperación

Una copia de seguridad no aporta garantías si nunca se ha restaurado. El plan debe incluir:

Datos.
ACL.
Propietarios.
Recursos compartidos.
Configuración.
Documentación.
Claves necesarias.
Procedimiento de restauración.

El objetivo no es únicamente recuperar los archivos, sino recuperar el servicio completo con sus permisos correctos.

Auditoría, sesiones y archivos abiertos

La auditoría permite reconstruir lo ocurrido. Para que resulte útil debe responder a una necesidad concreta.

En Windows, el proceso general es:

Definir los recursos que requieren seguimiento.
Activar las directivas de auditoría necesarias.
Configurar la SACL del archivo o la carpeta.
Realizar una operación permitida.
Realizar una operación denegada.
Consultar el registro de seguridad.
Correlacionar usuario, equipo, hora y recurso.
Ajustar el alcance para reducir el ruido.

Registrar todas las lecturas de todos los documentos puede generar un volumen difícil de gestionar. En muchos casos interesa centrarse en cambios, eliminaciones, accesos denegados o acciones sobre información sensible.

Sesiones SMB

PowerShell permite consultar las sesiones y los archivos abiertos:

Get-SmbSession |
  Select-Object ClientComputerName, ClientUserName, NumOpens

Get-SmbOpenFile |
  Select-Object FileId, ClientUserName, Path

Get-SmbConnection

Esta información muestra principalmente el estado actual. No sustituye a una auditoría histórica.

Para cerrar un archivo abierto puede utilizarse:

Close-SmbOpenFile -FileId 123456 -Force

Esta acción puede provocar pérdida de cambios. Antes de ejecutarla debemos:

Identificar el usuario.
Confirmar el archivo.
Valorar el impacto.
Avisar cuando sea posible.
Documentar la intervención.

Registros en Linux

En GNU/Linux podemos consultar:

journalctl -u nfs-server
journalctl -u cups
ausearch -f /srv/profesorado
last
ss -tnp

auditd permite registrar operaciones sobre rutas concretas. Su configuración debe ser precisa para evitar un volumen excesivo.

Los servidores también deberían mantener la hora sincronizada. Si cada equipo utiliza una hora diferente, resulta muy difícil relacionar un evento del cliente con otro del servidor.

Evidencias de una configuración correcta

Una práctica o implantación debería conservar:

Matriz de acceso.
Exportación o captura de las ACL.
Comandos ejecutados.
Salidas relevantes.
Prueba positiva.
Prueba negativa.
Registro de auditoría.
Conclusión.
Limitaciones conocidas.

La combinación de estas evidencias demuestra no solo que se realizó una configuración, sino que se interpretaron correctamente los resultados.

Cómo probar los permisos y resolver incidencias

Una configuración no está terminada hasta que se prueba desde un cliente.

En mi trabajo docente insisto especialmente en este punto. No considero demostrada una configuración porque funcione con la cuenta administradora. Para validarla debemos utilizar identidades representativas de cada rol y comprobar tanto las acciones permitidas como las que deberían ser rechazadas. Mi enfoque como profesor de Sistemas Operativos en Red busca convertir los conceptos técnicos en pruebas claras, aplicables y comprensibles.

Pruebas positivas

Una prueba positiva confirma que el usuario autorizado puede realizar la acción esperada.

Ejemplos:

El profesorado crea y modifica documentos.
El alumnado lee el material común.
Dirección accede a la carpeta confidencial.
El personal técnico administra permisos.
Un usuario envía un trabajo a la impresora.

Pruebas negativas

Una prueba negativa comprueba que el sistema rechaza una acción no autorizada.

Ejemplos:

El alumnado no elimina archivos del profesorado.
Un usuario sin grupo no accede a la carpeta.
Un empleado no administra los trabajos de impresión de otras personas.
Un cliente situado fuera de la red permitida no monta la exportación NFS.
Un usuario de lectura no modifica documentos.

Las pruebas negativas son tan importantes como las positivas. Una configuración puede permitir correctamente una operación y, al mismo tiempo, conceder más acceso del previsto.

Pruebas de límite

También debemos comprobar los límites:

Crear un archivo en la raíz, pero no en una subcarpeta.
Leer un documento, pero no modificarlo.
Crear elementos sin listar los de otros usuarios.
Acceder durante un horario autorizado.
Agotar una cuota controlada.
Abrir un archivo bloqueado.
Mover documentos entre ubicaciones con distinta herencia.

Secuencia general de diagnóstico

Ante una incidencia recomiendo seguir un orden fijo:

Confirmar el mensaje y la operación exacta que falla.
Identificar usuario, cliente, servidor, recurso y hora.
Comprobar conectividad.
Verificar la resolución de nombres.
Confirmar que el servicio está activo.
Comprobar que el recurso sigue publicado.
Revisar las credenciales utilizadas.
Consultar los grupos del usuario.
Revisar permisos del recurso compartido.
Revisar permisos del sistema de archivos.
Comprobar herencia y denegaciones.
Calcular el acceso efectivo.
Reproducir la incidencia.
Consultar sesiones y registros.
Aplicar el cambio mínimo.
Volver a probar.
Documentar la causa y la solución.

Este orden evita cambiar varias cosas a la vez. Cuando modificamos el firewall, los grupos, SMB y NTFS simultáneamente, podemos conseguir que el acceso funcione, pero no sabremos cuál era la causa.

Incidencias frecuentes en Windows

No se encuentra la ruta de red

Posibles causas:

Nombre incorrecto.
DNS.
Firewall.
Servidor apagado.
Servicio SMB detenido.
Recurso eliminado.

Comprobaciones:

Resolve-DnsName SRV-FICHEROS
Test-NetConnection SRV-FICHEROS -Port 445
Get-SmbShare

Solicitud repetida de credenciales

Puede deberse a:

Credenciales almacenadas incorrectas.
Identidad distinta a la esperada.
Problemas de dominio.
Diferencias de hora.
Sesiones previas abiertas.

Podemos revisar:

whoami
cmdkey /list
klist
net use

Acceso denegado

Las causas más habituales son:

Permiso SMB insuficiente.
Permiso NTFS insuficiente.
Entrada Denegar.
Grupo incorrecto.
Token de acceso antiguo.
Herencia inesperada.
Falta de permisos sobre una carpeta intermedia.

Debemos comparar ambas capas y cerrar la sesión si se ha modificado recientemente la pertenencia a grupos.

Puede leer, pero no modificar

Suele indicar que alguna de las capas solo permite lectura. El usuario puede disponer de Modificar en NTFS y Lectura en SMB, o al contrario.

Archivo bloqueado

Otro usuario o una aplicación puede mantenerlo abierto. Antes de forzar el cierre debemos identificar la sesión y valorar la posible pérdida de datos.

La carpeta no aparece

La enumeración basada en acceso puede ocultarla. También puede faltar permiso para listar su contenedor.

Incidencias frecuentes en Linux

Permission denied

Debemos revisar:

id usuario
namei -l /ruta/completa
getfacl /ruta/completa
exportfs -v

Las posibles causas incluyen:

UID o GID incorrecto.
Permisos POSIX.
ACL.
Máscara de ACL.
Falta de ejecución en un directorio.
Exportación de solo lectura.
Restricción del cliente autorizado.

El montaje NFS falla

Conviene comprobar:

systemctl status nfs-server
showmount -e servidor
exportfs -v
journalctl -u nfs-server

También debemos revisar firewall, DNS, versión de NFS y opciones de montaje.

Aparecen propietarios numéricos

Indica generalmente que el cliente no reconoce el UID o el GID recibido. Debemos comparar identidades en ambos equipos.

Los archivos se crean con el grupo incorrecto

Puede faltar el bit setgid o una ACL predeterminada. Debemos revisar:

ls -ld /srv/profesorado
getfacl /srv/profesorado

La impresora CUPS no responde

Hay que comprobar:

Conectividad.
URI.
Cola.
Controlador.
Formato.
Permisos.
Registros.

Reinstalar debería ser una de las últimas opciones, no la primera.

Errores que deben evitarse

Hay varias soluciones rápidas que suelen crear problemas mayores.

Conceder Control total a Todos

Puede hacer desaparecer momentáneamente una denegación, pero expone el recurso y oculta la causa original. La solución correcta consiste en identificar el permiso que falta y conceder únicamente el nivel necesario al grupo adecuado.

Probar siempre con una cuenta administradora

Una cuenta administrativa puede disponer de privilegios o pertenencias que no representan a los usuarios normales. Las pruebas deben ejecutarse con identidades reales de cada rol.

Modificar varias capas simultáneamente

Si cambiamos SMB, NTFS, grupos y firewall a la vez, no sabremos qué solucionó la incidencia. Debemos modificar una variable y volver a probar.

Eliminar la herencia sin analizar sus efectos

Desactivar la herencia puede retirar permisos necesarios o crear numerosas entradas explícitas difíciles de mantener.

Confundir ocultación con seguridad

Terminar el nombre del recurso con $ o utilizar enumeración basada en acceso no reemplaza las ACL.

Utilizar denegaciones para todo

Las denegaciones explícitas generan interacciones complejas con grupos y herencia. Deben utilizarse como excepción.

Cerrar archivos sin avisar

Forzar el cierre de un archivo puede provocar pérdida de trabajo. Debemos identificar al usuario y comunicar la intervención cuando sea posible.

No probar las copias

Una copia que nunca se ha restaurado es una suposición, no una garantía.

Mantener permisos indefinidamente

Los accesos envejecen. Deben revisarse cuando:

Una persona cambia de puesto.
Alguien abandona la organización.
Finaliza un proyecto.
Se detecta un incidente.
Vence un acceso temporal.
Cambia el propietario funcional del recurso.

La revisión debe comparar la matriz autorizada con la configuración real del servidor.

Conclusión

Los recursos compartidos en red son una pieza fundamental de cualquier infraestructura informática. Permiten centralizar documentos, facilitar el trabajo colaborativo, desplegar impresoras y administrar los datos desde un punto controlado. Esa comodidad, sin embargo, debe acompañarse de una estrategia clara de seguridad.

En Windows, debemos comprender cómo interactúan SMB y NTFS. Un permiso correcto en una capa no compensa una restricción en la otra. También debemos considerar el token de acceso, los grupos, la herencia, la propiedad y las posibles denegaciones.

En GNU/Linux, los recursos compartidos en red mediante NFS dependen de los permisos POSIX, las ACL, las opciones de exportación y la correspondencia de UID y GID. Una exportación puede estar perfectamente publicada y seguir fallando por un identificador incoherente o por la falta de ejecución en un directorio intermedio.

La mejor configuración no es la que contiene más reglas, sino la que responde a una necesidad documentada y puede mantenerse con facilidad. En mi caso, la combinación de desarrollo de software, consultoría y docencia me lleva a aplicar tres ideas: pensar con estructura, comprender la necesidad antes de elegir la herramienta y explicar la solución de forma que pueda comprobarse. Estas tres perspectivas forman parte de mi trayectoria profesional y encajan especialmente bien en la administración de sistemas.

Antes de dar por terminado un recurso, debemos realizar pruebas positivas y negativas. También necesitamos auditoría, copias verificadas y una revisión periódica de los permisos. Solo entonces podemos afirmar que los recursos compartidos en red son funcionales, seguros y mantenibles.

Preguntas frecuentes sobre recursos compartidos en red

¿Qué es un recurso compartido en red?

Es un archivo, carpeta, impresora, volumen o servicio que se publica para que pueda utilizarse desde otros equipos. Su acceso se controla mediante identidades, permisos y protocolos de red.

¿Qué diferencia existe entre acceso local y acceso remoto?

El acceso local se realiza directamente sobre el sistema de archivos del servidor. El acceso remoto utiliza un protocolo de red y puede incorporar capas adicionales. En Windows, el acceso por SMB combina permisos de recurso compartido y NTFS.

¿Qué protocolo se utiliza para compartir carpetas en Windows?

Windows utiliza principalmente SMB. Este protocolo permite compartir archivos, carpetas, impresoras y determinadas operaciones remotas.

¿Qué protocolo se utiliza para compartir directorios en Linux?

En entornos GNU/Linux y Unix se utiliza habitualmente NFS. El servidor exporta un directorio y el cliente lo monta dentro de su árbol local.

¿Cómo se combinan los permisos SMB y NTFS?

Cuando el acceso se realiza mediante la red, el resultado queda limitado por ambas capas. Si SMB permite lectura y NTFS permite modificar, el usuario solo podrá leer a través de la red.

¿Es mejor asignar permisos a usuarios o a grupos?

Resulta preferible asignarlos a grupos. Así, las altas, bajas y cambios de función se resuelven modificando pertenencias sin editar directamente las ACL de cada recurso.

¿Qué es el acceso efectivo?

Es el conjunto final de operaciones que una persona puede realizar después de considerar sus grupos, permisos explícitos, herencia, denegaciones y demás condiciones.

¿Un recurso terminado en `$` es seguro?

No. El símbolo $ evita que aparezca durante la exploración normal, pero el recurso sigue siendo accesible mediante su ruta si el usuario dispone de permisos.

¿Por qué un usuario puede leer, pero no modificar?

Alguna de las capas puede estar limitada a lectura. En Windows debemos revisar tanto SMB como NTFS. En Linux debemos comprobar permisos POSIX, ACL, máscara y opciones de montaje o exportación.

¿Por qué un cambio de grupo no se aplica inmediatamente?

En Windows, el token de acceso se genera al iniciar sesión. Puede ser necesario cerrar y volver a iniciar la sesión para que incluya la nueva pertenencia.

¿Qué función tiene `root_squash` en NFS?

Evita que el usuario root de un cliente conserve automáticamente privilegios de root sobre el recurso exportado. Es una medida importante para reducir riesgos.

¿Cómo se protege una carpeta compartida frente al ransomware?

Mediante mínimo privilegio, segmentación, actualizaciones, monitorización, cuentas separadas y copias desconectadas o inmutables. El antivirus por sí solo no resulta suficiente.

¿Qué pruebas deben hacerse después de compartir una carpeta?

Como mínimo, una prueba positiva con un usuario autorizado y una negativa con otro que no debería acceder. También conviene comprobar lectura, creación, modificación, eliminación, herencia y auditoría.

¿Qué debo revisar ante un acceso denegado?

Primero la identidad y los grupos. Después, conectividad, publicación del recurso, permisos SMB, permisos del sistema de archivos, herencia, entradas Denegar, acceso efectivo y registros.

¿La enumeración basada en acceso protege los datos?

No por sí sola. Oculta al usuario los elementos que no puede listar, pero la seguridad real depende de los permisos.

¡Volver al curso!

Hola, encantado de conocerte.

Regístrate para recibir las últimas entradas, cada domingo.