En Windows, cómo restringir el acceso a una carpeta, subcarpeta y archivos solo a algunas aplicaciones (no a usuarios)

Las aplicaciones en los sistemas operativos de Windows se ejecutan en el contexto del usuario que lo ejecuta y, por lo tanto, heredan el ACL de ese usuario.

Cuando se analiza de forma abstracta, su programa no hace nada más que Word (winword.exe) o Excel (excel.exe) con archivos .doc o .xls. No es necesario que restrinja el acceso a los datos solo a la aplicación, aunque la reducción de riesgos se produce:

• limitar a los usuarios que tienen acceso a los datos (ACL, también conocidos como permisos de archivos, idealmente a través de un grupo)
• limitar las operaciones que puede realizar un usuario (por ejemplo, la instalación de la aplicación para evitar el malware)
• lista blanca de aplicaciones
• protección antimalware
• auditoría de integridad de datos

En Unix, sugeriría que ejecute esa aplicación como un usuario o grupo en particular y limite los permisos de esa carpeta al usuario y al grupo.

Puedes hacer lo mismo en Windows, pero no tan fácilmente. Si conoce a todos los usuarios que ejecutarán la aplicación, ¿puede agregarlos a un grupo en particular y luego darle al grupo el control total sobre ese archivo?

Lo esencial de Android lo hace al instalar aplicaciones. Cada aplicación recibe un grupo asignado, y solo ese grupo puede acceder a los datos de la aplicación. En un sistema basado en Unix esto es bastante simple de implementar. Windows se pone un poco más difícil.

Listas de control de acceso

Lo que puedes hacer es crear una personalizada < em> Lista de control de acceso discrecional (DACL) para su aplicación. Estos se pueden convertir en Descriptores de seguridad que se pueden usar con funciones como CreateDirectory . La DACL contendrá toda la información sobre quién puede acceder a la carpeta. En este caso, probablemente querrá crear un grupo de Windows para la aplicación.

Cuando creas tu directorio, puedes restringir el acceso a la DACL que creas. Cuando su aplicación se ejecuta / necesita acceder al directorio, adquiere la DACL y la utiliza en las llamadas subsiguientes del sistema. Estos no son los objetos de Windows más fáciles del mundo para trabajar, pero hacen lo que usted quiere.

Más de lo que probablemente desee saber sobre los descriptores de seguridad de Windows y el acceso control.

Más información sobre cómo crear DACLs

Creando usuarios

Puedes crear un Perfil de usuario en Vista +. Más que un poco complicado porque Windows no fue diseñado para esto. Hacerse pasar por un usuario conectado requiere algún tipo de token de acceso para el usuario que está intentando usar. Hay funciones múltiples que devolverían tal token:

BOOL WINAPI ImpersonateLoggedOnUser(
  _In_  HANDLE hToken
);

  

hToken [in]

     

Un identificador para un token de acceso primario o de suplantación que   representa a un usuario conectado. Esto puede ser un identificador de token devuelto por un   llame a LogonUser , CreateRestrictedToken , DuplicateToken ,    DuplicateTokenEx , OpenProcessToken o OpenThreadToken . Si   hToken es un identificador de un token primario, el token debe tener TOKEN_QUERY   y TOKEN_DUPLICATE de acceso. Si hToken es un identificador de una suplantación.   token, el token debe tener acceso TOKEN_QUERY y TOKEN_IMPERSONATE .

LogonUser requiere una contraseña. Probablemente no quiera incluir el código uno en su aplicación. DuplicateToken solo genera tokens de suplantación de identidad, que no pueden usarse con CreateProcessAsUser (que es nuestro objetivo final). Ahora nos quedamos con un montón de funciones que requieren un token existente para duplicar y comenzar. Eso significa que te quedas con el token del usuario actual que no es lo que quieres.

Crear tokens es prácticamente imposible. Esa operación a menudo solo es realizada por LSASS, y no me sorprendería si todo este comportamiento estuviera marcado por Anti-virus. En Windows, este enfoque es probablemente una mala idea, y no vale la pena la cantidad de aros en llamas que tendrías que saltar para que funcione.