Segurança de ficheiros e direitos de acesso

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

Descritores de segurança

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 listas de controle de acesso (ACL) no descritor de segurança padrão para um arquivo ou diretório são herdadas de seu diretório pai. Observe que um descritor de segurança padrão é atribuído somente quando um arquivo ou diretório é recém-criado, e não quando ele é renomeado ou movido.

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

Direitos de acesso a ficheiros

Os direitos de acesso válidos para arquivos e diretórios incluem os DELETE, READ_CONTROL, WRITE_DAC, WRITE_OWNERe SYNCHRONIZEdireitos 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 dentro da lista de 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 deOVERLAPPEDconfigurada corretamente, em vez de usar o identificador de arquivo com o direito de acesso SYNCHRONIZE para sincronização.

A seguir estão 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 arquivo ou objeto de diretório. 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, consulte Interação entre threads e objetos protegíveis.

Por padrão, a autorização de 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 qualquer arquivo ou diretório filho. O FILE_TRAVERSEdireito de acesso pode ser aplicado removendo ode privilégios de BYPASS_TRAVERSE_CHECKING dos usuários. Isso não é recomendado no caso geral, pois muitos programas não lidam corretamente com erros de passagem de diretório. O principal uso para o direito de acesso FILE_TRAVERSE em diretórios é permitir a conformidade com certos padrões IEEE e ISO POSIX quando a interoperabilidade com sistemas Unix é um requisito.

O modelo de segurança do Windows fornece uma maneira para um diretório filho herdar, ou ser impedido de herdar, uma ou mais das 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 de diretório herdeiro. Por exemplo, algumas ACEs herdadas controlam o acesso ao objeto de diretório herdado, e elas são chamadas de ACEs efetivas. Todas as outras ACEs são chamadas ACEs somente hereditárias.

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 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 para baixo na hierarquia de diretórios.

Observe que você não pode usar uma ACE de acesso negado para negar apenas GENERIC_READ ou apenas GENERIC_WRITE acesso 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 GENERIC_WRITE acesso a um administrador fiduciário e o administrador solicitar GENERIC_READ acesso, a solicitação falhará porque a solicitação inclui implicitamente acesso SYNCHRONIZE que é implicitamente negado pela ACE e vice-versa. Em vez de usar ACEs de acesso negado, use ACEs de acesso permitido 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 Sistema de Arquivos Criptografados, ou EFS. O EFS encripta apenas ficheiros e não diretórios. A vantagem da criptografia é que ela fornece proteção adicional aos arquivos que é aplicada na mídia e não através do sistema de arquivos e da arquitetura de controle de acesso padrão do Windows. Para obter mais informações sobre encriptação de ficheiros, consulte File Encryption.

Backup e restauração de direitos de acesso

Na maioria dos casos, a capacidade de ler e gravar as configurações de segurança de um arquivo ou objeto de diretório é restrita a processos de modo kernel. Claramente, você não gostaria que nenhum processo de usuário pudesse alterar a propriedade ou restrição de 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 que você colocou no 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 diretório para garantir um backup completo. Da mesma forma, se um aplicativo de backup tentar gravar uma cópia de backup do arquivo sobre a cópia residente no disco e você negar explicitamente privilégios de gravação no processo do aplicativo de backup, a operação de restauração não poderá ser concluída. Neste caso também, o aplicativo de backup deve ser capaz de substituir as configurações de controle de acesso do seu arquivo.

Os privilégios de acesso SE_BACKUP_NAME e SE_RESTORE_NAME foram criados especificamente para fornecer essa capacidade de 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 READ_CONTROL padrão 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 seu arquivo e substitua a verificação de segurança padrão. Para restaurar o arquivo, o aplicativo de backup deve usar 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 no 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 processo do 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, em seguida, redefinir as configurações de controle de acesso.

Se um aplicativo de backup deve ter acesso às configurações de controle de acesso no nível do sistema, o sinalizador de ACCESS_SYSTEM_SECURITY deve 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.

Conteúdo relacionado

Direitos de acesso padrão