Segurança de arquivo e direitos de acesso

Como os arquivos são objetos protegíveis, o acesso a eles é regulamentado pelo modelo de controle de acesso que rege o acesso a todos os outros objetos protegíveis no Windows. Para obter uma explicação detalhada desse modelo, confira Controle de Acesso.

Você pode especificar um descritor de segurança para um arquivo ou diretório ao chamar a função CreateFile, CreateDirectory ou CreateDirectoryEx. Se você especificar NULL para o parâmetro lpSecurityAttributes, o arquivo ou diretório obterá um descritor de segurança padrão. As ACL (listas de controle de acesso) no descritor de segurança padrão para um arquivo ou diretório são herdadas do diretório pai. Observe que um descritor de segurança padrão é atribuído somente quando um arquivo ou diretório é criado recentemente e não quando é renomeado ou movido.

Para recuperar o descritor de segurança de um arquivo ou objeto do directory, chame a função GetNamedSecurityInfo ou GetSecurityInfo. Para alterar o descritor de segurança de um arquivo ou objeto do directory, chame a função SetNamedSecurityInfo ou SetSecurityInfo.

Os direitos de acesso válidos para arquivos e diretórios incluem DELETE, READ_CONTROL, WRITE_DAC, WRITE_OWNER e SYNCHRONIZE como direitos de acesso padrão. A tabela em Constantes de direitos de acesso a arquivos lista os direitos de acesso específicos para arquivos e diretórios.

Embora o direito de acesso SYNCHRONIZE seja definido na lista de direitos de acesso padrão como o direito de especificar um identificador de arquivo em uma das funções de espera, ao usar operações de E/S de arquivo assíncronas, você deve aguardar o identificador de evento contido em uma estrutura OVERLAPPED configurada corretamente em vez de usar o identificador de arquivo com o direito de acesso SYNCHRONIZE para sincronização.

Veja a seguir os direitos de acesso genéricos para arquivos e diretórios.

O Windows compara os direitos de acesso solicitados e as informações no token de acesso do thread com as informações no descritor de segurança do objeto de arquivo ou do directory. Se a comparação não proibir que todos os direitos de acesso solicitados sejam concedidos, um identificador para o objeto será retornado ao thread e os direitos de acesso serão concedidos. Para obter mais informações sobre esse processo, confira Interação entre threads e objetos protegíveis.

Por padrão, a autorização para acesso a um arquivo ou diretório é controlada estritamente pelas ACLs no descritor de segurança associado a esse arquivo ou diretório. Em particular, o descritor de segurança de um diretório pai não é usado para controlar o acesso a nenhum arquivo ou diretório filho. O direito de acesso FILE_TRAVERSE pode ser imposto removendo o privilégio BYPASS_TRAVERSE_CHECKING dos usuários. Isso não é recomendado no geral, pois muitos programas não lidam corretamente com erros de passagem de diretório. O uso principal para o direito de acesso FILE_TRAVERSE em diretórios é habilitar a conformidade com determinados padrões IEEE e ISO POSIX quando a interoperabilidade com sistemas Unix é um requisito.

O modelo de segurança do Windows fornece uma maneira de um diretório filho herdar ou ser impedido de herdar um ou mais ACEs no descritor de segurança do diretório pai. Cada ACE contém informações que determinam como ela pode ser herdada e se terá um efeito sobre o objeto do directory herdado. Por exemplo, alguns ACEs herdados controlam o acesso ao objeto do directory herdado e são chamados de ACEs eficazes. Todos os outros ACEs são chamados de ACEs somente herdados.

O modelo de segurança do Windows também impõe a herança automática de ACEs a objetos filho de acordo com as regras de herança de ACE. Essa herança automática, juntamente com as informações de herança em cada ACE, determina como as restrições de segurança são passadas na hierarquia de diretórios.

Observe que você não pode usar uma ACE com acesso negado para negar apenas GENERIC_READ ou apenas acesso GENERIC_WRITE a um arquivo. Isso ocorre porque, para objetos de arquivo, os mapeamentos genéricos para GENERIC_READ ou GENERIC_WRITE incluem o direito de acesso SYNCHRONIZE. Se uma ACE negar o acesso GENERIC_WRITE a um administrador e o administrador solicitar o acesso GENERIC_READ, a solicitação falhará porque a solicitação incluirá implicitamente o acesso SYNCHRONIZE, que é implicitamente negado pela ACE e vice-versa. Em vez de usar ACEs negadas pelo acesso, use ACEs com permissão de acesso para permitir explicitamente os direitos de acesso permitidos.

Outro meio de gerenciar o acesso a objetos de armazenamento é a criptografia. A implementação da criptografia do sistema de arquivos no Windows é o EFS ou sistema de arquivos com criptografia. O EFS criptografa apenas arquivos e não diretórios. A vantagem da criptografia é que ela fornece proteção adicional aos arquivos que são aplicados na mídia e não por meio do sistema de arquivos e da arquitetura de controle de acesso padrão do Windows. Para obter mais informações sobre criptografia de arquivo, confira Criptografia de arquivo.

Na maioria dos casos, a capacidade de ler e gravar as configurações de segurança de um arquivo ou objeto do directory é restrita a processos no modo kernel. Claramente, você não deseja que nenhum processo de usuário possa alterar a restrição de propriedade ou acesso em seu arquivo ou diretório privado. No entanto, um aplicativo de backup não poderá concluir seu trabalho de backup do arquivo se as restrições de acesso colocadas em seu arquivo ou diretório não permitirem que o processo de modo de usuário do aplicativo o leia. Os aplicativos de backup devem ser capazes de substituir as configurações de segurança de objetos de arquivo e do directory para garantir um backup completo. Da mesma forma, se um aplicativo de backup tentar gravar uma cópia de backup do arquivo na cópia residente em disco e você negar explicitamente privilégios de gravação para o processo de aplicativo de backup, a operação de restauração não poderá ser concluída. Nesse caso também, o aplicativo de backup deve ser capaz de substituir as configurações de controle de acesso do arquivo.

Os privilégios de acesso SE_BACKUP_NAME e SE_RESTORE_NAME foram criados especificamente para fornecer essa capacidade de fazer backup de aplicativos. Se esses privilégios tiverem sido concedidos e habilitados no token de acesso do processo do aplicativo de backup, ele poderá chamar CreateFile para abrir seu arquivo ou diretório para backup, especificando o direito de acesso padrão READ_CONTROL como o valor do parâmetro dwDesiredAccess. No entanto, para identificar o processo de chamada como um processo de backup, a chamada para CreateFile deve incluir o sinalizador FILE_FLAG_BACKUP_SEMANTICS no parâmetro dwFlagsAndAttributes. A sintaxe completa da chamada de função é a seguinte:

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

Isso permitirá que o processo do aplicativo de backup abra o arquivo e substitua a verificação de segurança padrão. Para restaurar o arquivo, o aplicativo de backup usaria a seguinte sintaxe de chamada CreateFile ao abrir o arquivo a ser gravado.

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

Há situações em que um aplicativo de backup deve ser capaz de alterar as configurações de controle de acesso de um arquivo ou diretório. Um exemplo é quando as configurações de controle de acesso da cópia residente em disco de um arquivo ou diretório são diferentes da cópia de backup. Isso aconteceria se essas configurações fossem alteradas após o backup do arquivo ou diretório ou se ele estivesse corrompido.

O sinalizador FILE_FLAG_BACKUP_SEMANTICS especificado na chamada para CreateFile dá ao aplicativo de backup permissão para ler as configurações de controle de acesso do arquivo ou diretório. Com essa permissão, o processo do aplicativo de backup pode chamar GetKernelObjectSecurity e SetKernelObjectSecurity para ler e redefinir as configurações de controle de acesso.

Se um aplicativo de backup precisar ter acesso às configurações de controle de acesso no nível do sistema, o sinalizador ACCESS_SYSTEM_SECURITY deverá ser especificado no valor do parâmetro dwDesiredAccess passado para CreateFile.

Os aplicativos de backup chamam BackupRead para ler os arquivos e diretórios especificados para a operação de restauração e BackupWrite para gravá-los.

Tópicos relacionados

direitos de acesso padrão