Sécurité du fichier et droits d’accès

Étant donné que les fichiers sont des objets sécurisables, leur accès est réglementé par le modèle de contrôle d’accès qui régit l’accès à tous les autres objets sécurisables dans Windows. Pour obtenir une explication détaillée de ce modèle, consultez Contrôle d’accès.

Vous pouvez spécifier un descripteur de sécurité pour un fichier ou un répertoire lorsque vous appelez la fonction CreateFile, CreateDirectory ou CreateDirectoryEx. Si vous spécifiez NULL pour le paramètre lpSecurityAttributes, le fichier ou le répertoire obtient un descripteur de sécurité par défaut. Les listes de contrôle d’accès (ACL) du descripteur de sécurité par défaut d’un fichier ou d’un répertoire sont héritées de son répertoire parent. Notez qu’un descripteur de sécurité par défaut n’est attribué que lorsqu’un fichier ou un répertoire est nouvellement créé, et non lorsqu’il est renommé ou déplacé.

Pour récupérer le descripteur de sécurité d’un fichier ou d’un objet répertoire, appelez la fonction GetNamedSecurityInfo ou GetSecurityInfo. Pour modifier le descripteur de sécurité d’un fichier ou d’un objet répertoire, appelez la fonction SetNamedSecurityInfo ou SetSecurityInfo.

Les droits d’accès valides pour les fichiers et les répertoires incluent les droits d’accès standard DELETE, READ_CONTROL, WRITE_DAC, WRITE_OWNER et SYNCHRONIZE . Le tableau des Constantes des droits d’accès aux fichiers énumère les droits d’accès spécifiques aux fichiers et aux répertoires.

Bien que le droit d’accès SYNCHRONIZE soit défini dans la liste standard des droits d’accès comme le droit de spécifier un descripteur de fichier dans l’une des fonctions d’attente, lorsque vous utilisez des opérations d’E/S de fichier asynchrones, vous devez attendre le descripteur d’événement contenu dans une structure OVERLAPPED correctement configurée plutôt que d’utiliser le descripteur de fichier avec le droit d’accès SYNCHRONIZE pour la synchronisation.

Les droits d’accès génériques aux fichiers et aux répertoires sont les suivants.

Windows compare les droits d’accès demandés et les informations contenues dans le jeton d’accès du thread avec les informations contenues dans le descripteur de sécurité de l’objet fichier ou répertoire. Si la comparaison n’interdit pas l’octroi de tous les droits d’accès demandés, un descripteur de l’objet est renvoyé au thread et les droits d’accès sont accordés. Pour plus d’informations sur ce processus, voir Interaction entre les threads et les objets sécurisables.

Par défaut, l’autorisation d’accès à un fichier ou à un répertoire est strictement contrôlée par les listes de contrôle d’accès (ACL) du descripteur de sécurité associé à ce fichier ou à ce répertoire. En particulier, le descripteur de sécurité d’un répertoire parent n’est pas utilisé pour contrôler l’accès à un fichier ou à un répertoire enfant. Le droit d'accès FILE_TRAVERSE peut être appliqué en supprimant le privilège BYPASS_TRAVERSE_CHECKING des utilisateurs. Cela n’est pas recommandé dans le cas général, car de nombreux programmes ne gèrent pas correctement les erreurs de traversée de répertoire. La principale utilisation du droit d’accès FILE_TRAVERSE sur les répertoires est de permettre la conformité à certaines normes POSIX IEEE et ISO lorsque l’interopérabilité avec les systèmes Unix est une exigence.

Le modèle de sécurité Windows permet à un répertoire enfant d’hériter, ou d’être empêché d’hériter, d’un ou plusieurs des ACE du descripteur de sécurité du répertoire parent. Chaque ACE contient des informations qui déterminent comment il peut être hérité et s’il aura un effet sur l’objet répertoire héritant. Par exemple, certaines ACE héritées contrôlent l’accès à l’objet répertoire hérité et sont appelées ACE effectives. Toutes les autres ACE sont appelées ACE héritées uniquement.

Le modèle de sécurité Windows applique également l’héritage automatique des ACE aux objets enfants conformément aux règles d’héritage des ACE. Cet héritage automatique, ainsi que les informations relatives à l’héritage dans chaque ACE, déterminent la manière dont les restrictions de sécurité sont transmises à la hiérarchie des répertoires.

Notez que vous ne pouvez pas utiliser un ACE de refus d’accès pour refuser uniquement l’accès GENERIC_READ ou uniquement l’accès GENERIC_WRITE à un fichier. En effet, pour les objets fichiers, les mappages génériques pour GENERIC_READ ou GENERIC_WRITE incluent le droit d’accès SYNCHRONIZE. Si un ACE refuse l’accès GENERIC_WRITE à un administrateur et que ce dernier demande l’accès GENERIC_READ, la demande échouera car elle inclut implicitement l’accès SYNCHRONIZE qui est implicitement refusé par le ACE, et vice versa. Au lieu d’utiliser des ACE de refus d’accès, utilisez des ACE d’autorisation d’accès pour autoriser explicitement les droits d’accès autorisés.

Le chiffrement est un autre moyen de gérer l’accès aux objets de stockage. L’implémentation du chiffrement du système de fichiers dans Windows est le système de fichiers chiffrés, ou EFS. EFS ne chiffre que les fichiers et non les répertoires. L’avantage du chiffrement est qu’il fournit une protection supplémentaire aux fichiers qui est appliquée sur le support et non par l’intermédiaire du système de fichiers et de l’architecture standard de contrôle d’accès de Windows. Pour plus d’informations sur le chiffrement des fichiers, voir Chiffrement des fichiers.

Dans la plupart des cas, la possibilité de lire et d’écrire les paramètres de sécurité d’un fichier ou d’un objet annuaire est limitée aux processus en mode noyau. Il est évident que vous ne souhaitez pas qu’un processus utilisateur puisse modifier la propriété ou les restrictions d’accès à votre fichier ou répertoire privé. Cependant, une application de sauvegarde ne pourra pas terminer son travail de sauvegarde de votre fichier si les restrictions d’accès que vous avez placées sur votre fichier ou répertoire ne permettent pas au processus en mode utilisateur de l’application de le lire. Les applications de sauvegarde doivent être en mesure d’outrepasser les paramètres de sécurité des fichiers et des répertoires afin de garantir une sauvegarde complète. De même, si une application de sauvegarde tente d’écrire une copie de sauvegarde de votre fichier sur la copie résidant sur le disque et que vous refusez explicitement les privilèges d’écriture à l’application de sauvegarde, l’opération de restauration ne peut pas s’achever. Dans ce cas également, l’application de sauvegarde doit être en mesure d’ignorer les paramètres de contrôle d’accès de votre fichier.

Les privilèges d’accès SE_BACKUP_NAME et SE_RESTORE_NAME ont été spécifiquement créés pour permettre la sauvegarde des applications. Si ces privilèges ont été accordés et activés dans le jeton d’accès du processus d’application de sauvegarde, celui-ci peut alors appeler CreateFile pour ouvrir votre fichier ou répertoire pour la sauvegarde, en spécifiant le droit d’accès standard READ_CONTROL comme valeur du paramètre dwDesiredAccess. Toutefois, pour identifier le processus appelant comme un processus de sauvegarde, l’appel à CreateFile doit inclure l’indicateur FILE_FLAG_BACKUP_SEMANTICS dans le paramètre dwFlagsAndAttributes. La syntaxe complète de l’appel de fonction est la suivante :

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

Cela permettra au processus d’application de la sauvegarde d’ouvrir votre fichier et de passer outre le contrôle de sécurité standard. Pour restaurer votre fichier, l’application de sauvegarde doit utiliser la syntaxe d’appel CreateFile suivante lors de l’ouverture du fichier à écrire.

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

Dans certains cas, une application de sauvegarde doit pouvoir modifier les paramètres de contrôle d’accès d’un fichier ou d’un répertoire. C’est le cas, par exemple, lorsque les paramètres de contrôle d’accès de la copie d’un fichier ou d’un répertoire résidant sur le disque sont différents de ceux de la copie de sauvegarde. Cela se produit si ces paramètres ont été modifiés après la sauvegarde du fichier ou du répertoire, ou s’ils ont été corrompus.

L’indicateur FILE_FLAG_BACKUP_SEMANTICS spécifié dans l’appel à CreateFile autorise le processus d’application de sauvegarde à lire les paramètres de contrôle d’accès du fichier ou du répertoire. Avec cette autorisation, le processus de l’application de sauvegarde peut alors appeler GetKernelObjectSecurity et SetKernelObjectSecurity pour lire puis réinitialiser les paramètres de contrôle d’accès.

Si une application de sauvegarde doit avoir accès aux paramètres de contrôle d’accès au niveau du système, l’indicateur ACCESS_SYSTEM_SECURITY doit être spécifié dans la valeur du paramètre dwDesiredAccess transmise à CreateFile.

Les applications de sauvegarde appellent BackupRead pour lire les fichiers et répertoires spécifiés pour l’opération de restauration, et BackupWrite pour les écrire.

Rubriques connexes

droits d’accès standard