Seguridad y derechos de acceso de los archivos

Dado que los archivos son objetos que se pueden proteger, el acceso a ellos está regulado por el modelo de control de acceso que rige el acceso a todos los demás objetos que se pueden proteger en Windows. Para obtener una explicación detallada de este modelo, consulte Control de acceso.

Puede especificar un descriptor de seguridad para un archivo o directorio al llamar a la función CreateFile, CreateDirectory o CreateDirectoryEx. Si especifica NULL para el parámetro lpSecurityAttributes, el archivo o directorio obtiene un descriptor de seguridad predeterminado. Las listas de control de acceso (ACL) del descriptor de seguridad predeterminado para un archivo o directorio se heredan de su directorio primario. Tenga en cuenta que solo se asigna un descriptor de seguridad predeterminado cuando se acaba de crear un archivo o directorio y no cuando se cambia el nombre o se mueve.

Para recuperar el descriptor de seguridad de un objeto de archivo o de directorio, llame a la función GetNamedSecurityInfo o GetSecurityInfo. Para cambiar el descriptor de seguridad de un objeto de archivo o de directorio, llame a la función SetNamedSecurityInfo o SetSecurityInfo.

Los derechos de acceso válidos para archivos y directorios incluyen los derechos de acceso estándar DELETE, READ_CONTROL, WRITE_DAC, WRITE_OWNER y SYNCHRONIZE. La tabla de Constantes de los derechos de acceso a archivos enumera los derechos de acceso específicos de los archivos y directorios.

Aunque el derecho de acceso SYNCHRONIZE se define dentro de la lista de derechos de acceso estándar como el derecho para especificar un identificador de archivo en una de las funciones de espera, cuando use operaciones asincrónicas de E/S de archivos, debe esperar el identificador de eventos contenido en una estructura SUPERPUESTA configurada correctamente en lugar de usar el identificador de archivo con el derecho de acceso SYNCHRONIZE para la sincronización.

A continuación, se muestran los derechos de acceso genéricos para archivos y directorios.

Windows compara los derechos de acceso solicitados y la información del token de acceso del subproceso con la información del descriptor de seguridad del objeto de archivo o directorio. Si la comparación no prohíbe que se concedan todos los derechos de acceso solicitados, se devuelve un identificador al objeto al subproceso y se conceden los derechos de acceso. Para obtener más información sobre este proceso, consulte Interacción entre subprocesos y objetos que se pueden proteger.

De manera predeterminada, la autorización para el acceso a un archivo o directorio se controla estrictamente mediante las ACL del descriptor de seguridad asociado a ese archivo o directorio. En particular, no se usa el descriptor de seguridad de un directorio primario para controlar el acceso a ningún archivo o directorio secundario. El derecho de acceso FILE_TRAVERSE se puede aplicar quitando el privilegio BYPASS_TRAVERSE_CHECKING de los usuarios. Esto no se recomienda en el caso general, ya que muchos programas no controlan correctamente los errores de cruce de directorio. El uso principal del derecho de acceso FILE_TRAVERSE en los directorios es habilitar la conformidad con determinados estándares IEEE e ISO POSIX cuando la interoperabilidad con sistemas Unix es un requisito.

El modelo de seguridad de Windows proporciona una manera de que un directorio secundario herede, o de impedir que herede, uno o varios de los ACE del descriptor de seguridad del directorio primario. Cada ACE contiene información que determina cómo se puede heredar y si tendrá un efecto en el objeto de directorio heredado. Por ejemplo, algunos ACE heredados controlan el acceso al objeto de directorio heredado y estos se llaman ACE eficaces. Todos los demás ACE se llaman ACE de solo herencia.

El modelo de seguridad de Windows también aplica la herencia automática de ACE a objetos secundarios según las reglas de herencia de ACE. Esta herencia automática, junto con la información de herencia de cada ACE, determina cómo se pasan las restricciones de seguridad a la jerarquía de directorios.

Tenga en cuenta que no puede usar un ACE de acceso denegado para denegar solo el acceso GENERIC_READ o solo GENERIC_WRITE a un archivo. Esto se debe a que para los objetos de archivo, las asignaciones genéricas de GENERIC_READ o GENERIC_WRITE incluyen el derecho de acceso SYNCHRONIZE. Si un ACE deniega el acceso GENERIC_WRITE a un administrador y el administrador solicita el acceso GENERIC_READ, se producirá un error en la solicitud porque la solicitud incluye implícitamente el acceso SYNCHRONIZE que el ACE deniega implícitamente y viceversa. En lugar de usar un ACE de acceso denegado, use un ACE de acceso permitido para permitir explícitamente los derechos de acceso permitidos.

Otro medio para administrar el acceso a los objetos de almacenamiento es el cifrado. La implementación del cifrado del sistema de archivos en Windows es el Sistema de cifrado de archivos o EFS. EFS solo cifra archivos y no directorios. La ventaja del cifrado es que proporciona una protección adicional a los archivos que se aplica en el medio y no mediante el sistema de archivos y la arquitectura estándar de control de acceso de Windows. Para obtener más información sobre el cifrado de archivos, consulte Cifrado de archivos.

En la mayoría de los casos, la capacidad de leer y escribir la configuración de seguridad de un objeto de archivo o directorio está restringida a los procesos en modo kernel. Claramente, no desea que ningún proceso de usuario pueda cambiar la propiedad o la restricción de acceso en el archivo o directorio privado. Sin embargo, una aplicación de copia de seguridad no podría completar su trabajo de copia de seguridad del archivo si las restricciones de acceso que ha colocado en el archivo o directorio no permiten que el proceso en modo de usuario de la aplicación lo lea. Las aplicaciones de copia de seguridad deben poder invalidar la configuración de seguridad de los objetos de archivo y directorio para garantizar una copia de seguridad completa. De forma similar, si una aplicación de copia de seguridad intenta escribir una copia de seguridad del archivo sobre la copia residente en disco y se deniegan explícitamente los privilegios de escritura al proceso de la aplicación de copia de seguridad, la operación de restauración no se puede completar. En este caso también, la aplicación de copia de seguridad debe poder invalidar la configuración de control de acceso del archivo.

Los privilegios de acceso SE_BACKUP_NAME y SE_RESTORE_NAME se crearon específicamente para proporcionar esta capacidad a las aplicaciones de copia de seguridad. Si se han concedido y habilitado estos privilegios en el token de acceso del proceso de la aplicación de copia de seguridad, esta puede llamar a CreateFile para abrir el archivo o directorio para la copia de seguridad, especificando el derecho de acceso estándar READ_CONTROL como el valor del parámetro dwDesiredAccess. Sin embargo, para identificar al proceso del autor de la llamada como proceso de copia de seguridad, la llamada a CreateFile debe incluir la marca FILE_FLAG_BACKUP_SEMANTICS en el parámetro dwFlagsAndAttributes. La sintaxis completa de la llamada de función es la siguiente:

HANDLE hFile = CreateFile( fileName,                   // lpFileName
                           READ_CONTROL,               // dwDesiredAccess
                           0,                          // dwShareMode
                           NULL,                       // lpSecurityAttributes
                           OPEN_EXISTING,              // dwCreationDisposition
                           FILE_FLAG_BACKUP_SEMANTICS, // dwFlagsAndAttributes
                           NULL );                     // hTemplateFile

Esto permitirá que el proceso de la aplicación de copia de seguridad abra el archivo e invalide la comprobación de seguridad estándar. Para restaurar el archivo, la aplicación de copia de seguridad usaría la siguiente sintaxis de llamada a CreateFile al abrir el archivo que se va a escribir.

HANDLE hFile = CreateFile( fileName,                   // lpFileName
                           WRITE_OWNER | WRITE_DAC,    // dwDesiredAccess
                           0,                          // dwShareMode
                           NULL,                       // lpSecurityAttributes
                           CREATE_ALWAYS,              // dwCreationDisposition
                           FILE_FLAG_BACKUP_SEMANTICS, // dwFlagsAndAttributes
                           NULL );                     // hTemplateFile

Hay situaciones en las que una aplicación de copia de seguridad debe poder cambiar la configuración de control de acceso de un archivo o directorio. Se produce un ejemplo cuando la configuración de control de acceso de la copia residente en disco de un archivo o directorio es diferente de la copia de seguridad. Esto sucedería si se cambiaran estas configuraciones después de que se realizara la copia de seguridad del archivo o directorio, o si estaba dañada.

La marca FILE_FLAG_BACKUP_SEMANTICS especificada en la llamada a CreateFile concede al proceso de la aplicación de copia de seguridad permiso para leer la configuración de control de acceso del archivo o directorio. Con este permiso, el proceso de la aplicación de copia de seguridad puede llamar a GetKernelObjectSecurity y SetKernelObjectSecurity para leer y después restablecer la configuración de control de acceso.

Si una aplicación de copia de seguridad debe tener acceso a la configuración de control de acceso de nivel de sistema, se debe especificar la marca ACCESS_SYSTEM_SECURITY en el valor del parámetro dwDesiredAccess que se pasa a CreateFile.

Las aplicaciones de copia de seguridad llaman a BackupRead para leer los archivos y directorios especificados para la operación de restauración y a BackupWrite para escribirlos.

Temas relacionados

Derechos de acceso estándar