Cas d’utilisation pour le reclassement de sécurité
L'héritage de sécurité est applicable uniquement aux répertoires et aux onglets. Lorsque la sécurité est définie sur Hériter pour un répertoire ou un onglet, le processus de reclassement définit la même sécurité sur les sous-répertoires et toutes les versions des documents dans ces répertoires et onglets. Dans les cas où un utilisateur définit la sécurité par défaut d'un répertoire à une valeur explicite (Public, Privé ou Aperçu), le reclassement suppose que l'utilisateur a l'intention de gérer sa sécurité manuellement. Le reclassement saute le traitement des répertoires lorsque l'héritage est rompu. Par défaut, toutes les modifications que vous apportez à la sécurité d'un répertoire ou d'un onglet pendant un transfert sont héritées par les sous-répertoires et les documents de ce répertoire ou de cet onglet.
Ce chapitre explique certains des cas d'utilisation courants que vous rencontrez dans le système iManage Work et les propositions possibles par reclassement.
Cas d’utilisation du reclassement de la sécurité
Ce chapitre explique certains des cas d'utilisation courants que vous rencontrez dans le système iManage Work et les propositions possibles par reclassement.
Modification de la sécurité par défaut d'un conteneur
L'exemple suivant explique les résultats d'une proposition de modification de la sécurité par défaut d'un répertoire sur les éléments subordonnés dans et sous ce conteneur.
Dans cet exemple , un événement de reclassement de sécurité est déclenché en changeant la sécurité par défaut d'un répertoire parent en Public. Au fur et à mesure que la modification se propage aux éléments enfants, un document (cas 1) a sa sécurité par défaut définie sur Public. La sécurité par défaut de ce document n'est pas modifiée car les deux paramètres (la sécurité par défaut proposée et la sécurité par défaut actuelle du document) sont les mêmes, et l'une des règles de reclassement consiste à ne jamais modifier des paramètres identiques. Cependant, si le paramètre de sécurité par défaut du document est Aperçu (cas 5), sa sécurité par défaut est mise à jour en Public.
|
Cas |
État proposé par |
État actuel |
Résultat |
Règle associée |
|
1 |
La sécurité par défaut est sur Public |
La sécurité par défaut est sur Public. |
Aucune modification. |
Les éléments ayant une sécurité par défaut identique ne sont pas reclassés pour la sécurité. |
|
2 |
La sécurité par défaut est sur Public |
Le document est restreint. |
Aucune modification. |
Les éléments marqués comme étant restreints ne sont pas reclassés pour la sécurité. |
|
3 |
La sécurité par défaut est sur Public |
Le document est sécurisé et le document sécurisé reclassé est Non |
Aucune modification. |
Document sécurisé |
|
4 |
La sécurité par défaut est sur Public |
Le document est sécurisé et le document sécurisé reclassé est Oui |
La sécurité par défaut est modifiée sur Public. |
Document sécurisé |
|
5 |
La sécurité par défaut est sur Public |
La sécurité par défaut est sur Aperçu. |
La sécurité par défaut est modifiée sur Public. |
Mise à jour autorisée. |
|
6 |
La sécurité par défaut est sur Privé |
La sécurité par défaut est sur Public. |
La sécurité par défaut est modifiée sur Privé. |
Mise à jour autorisée. |
|
7 |
La sécurité par défaut est sur Privé |
Le document est restreint. |
Aucune modification. |
Les éléments marqués comme étant restreints ne sont pas reclassés pour la sécurité. |
|
8 |
La sécurité par défaut est sur Privé |
Le document est sécurisé et le document sécurisé reclassé est réglé sur Non |
Aucune modification. |
Document sécurisé |
|
9 |
La sécurité par défaut est sur Privé |
Le document est sécurisé et le document sécurisé reclassé est Oui |
La sécurité par défaut est modifiée sur Privé. |
Mise à jour autorisée. Document sécurisé |
|
10 |
La sécurité par défaut est sur Privé |
La sécurité par défaut est sur Aperçu. |
La sécurité par défaut devient Privé |
Mise à jour autorisée. |
|
11 |
La sécurité par défaut est sur Aperçu |
La sécurité par défaut est sur Public. |
La sécurité par défaut devient Aperçu. |
Mise à jour autorisée. |
|
12 |
La sécurité par défaut est sur Aperçu |
Le document est restreint. |
Aucune modification. |
Les éléments marqués comme étant restreints ne sont pas reclassés pour la sécurité. |
|
13 |
La sécurité par défaut est sur Aperçu |
Le document est sécurisé et le document sécurisé reclassé est réglé sur Non |
Aucune modification. |
Document sécurisé |
|
14 |
La sécurité par défaut est sur Aperçu |
Le document est sécurisé et le document sécurisé reclassé est réglé sur Oui |
La sécurité par défaut devient Aperçu. |
Mise à jour autorisée. Document sécurisé |
|
15 |
La sécurité par défaut est sur Aperçu |
La sécurité par défaut est sur Aperçu. |
Aucune modification. |
Les éléments ayant une sécurité par défaut identique ne sont pas reclassés pour la sécurité. |
Ajout d'un utilisateur à un conteneur
Le tableau explique les résultats d'une proposition de modification de l'ajout d'un utilisateur à un espace de travail ou à un répertoire.
Dans cet exemple, un événement de reclassement de sécurité est déclenché par l'ajout de l'utilisateur ACASE à l'accès en lecture/écriture. Au fur et à mesure que la modification se propage aux éléments enfants, un document (cas 1) a actuellement sa sécurité par défaut définie sur Restreint. La sécurité par défaut du document ne change pas parce qu'un document avec une sécurité par défaut sur Restreint n'est jamais modifié.
|
Cas |
État proposé par |
État actuel |
Résultat |
Règle associée |
|
1 |
L'utilisateur ACASE obtient un accès en lecture/écriture |
Le document est restreint. |
Aucune modification. |
Les éléments marqués comme étant restreints ne sont pas reclassés pour la sécurité. |
|
2 |
L'utilisateur ACASE obtient un accès en lecture/écriture |
Le document est sécurisé et le document sécurisé reclassé est réglé sur Non |
Aucune modification. |
Document sécurisé. |
|
3 |
L'utilisateur ACASE obtient un accès en lecture/écriture |
Le document est sécurisé et le document sécurisé reclassé est réglé sur Oui |
L'utilisateur ACASE se voit attribuer un accès en lecture/écriture. |
Mise à jour autorisée. Document sécurisé. |
|
4 |
L’utilisateur ACASE n'obtient aucun accès |
Le document n'est ni restreint ni sécurisé. |
L'utilisateur ACASE n’obtient aucun accès et ne peut pas accéder aux conteneurs ou aux éléments dans ces conteneurs. |
Mise à jour autorisée. |
Modification du niveau d'accès d'un utilisateur
L'exemple suivant explique les résultats d'une proposition de changement sur la modification du niveau d'accès d'un utilisateur existant d'un espace de travail ou d'un répertoire.
Dans cet exemple, un document (cas 3) n'est actuellement ni restreint ni sécurisé et l'utilisateur ACASE n'a aucun accès assigné à son conteneur parent. Un événement de reclassement de sécurité est déclenché en modifiant l'accès d'ACASE pour obtenir l'accès complet au conteneur parent. Comme la modification se propage jusqu'à ses enfants, le document n’est pas modifié pas et ACASE n'obtient pas l’accès complet au document. Ceci est dû au fait qu'une règle Reclassement indique qu'un utilisateur explicitement assigné avec aucun accès n’est jamais modifié.
|
Cas |
État proposé par |
État actuel du document |
Résultat |
Règle associée |
|
1a |
L'utilisateur ACASE obtient un accès en lecture/écriture |
Le document est sécurisé et le document sécurisé reclassé est réglé sur Non |
Aucune modification. |
Document sécurisé. |
|
1b |
L'utilisateur ACASE obtient un accès en lecture/écriture |
Le document est sécurisé et le document sécurisé reclassé est réglé sur Oui |
L'accès d'ACASE sur le document est écrasé par l'accès en lecture/écriture. |
Mise à jour autorisée. Voir la règle Documents sécurisé. |
|
2 |
L’utilisateur ACASE n'obtient aucun accès |
Le document n'est ni restreint ni sécurisé, et ACASE y a un accès explicite. |
L'accès d'ACASE sur le document est écrasé par Aucun accès. |
Mise à jour autorisée. |
|
3 |
L’utilisateur ACASE obtient l’accès complet |
Le document n'est ni restreint ni sécurisé, et ACASE n'a explicitement aucun accès au document. |
Aucune modification. |
Les utilisateurs n’ayant aucun accès ne voient jamais leur niveau d'accès explicite modifié par un reclassement de sécurité. Pour modifier un utilisateur n’ayant Aucun accès, vous devez prendre des mesures supplémentaires. Voir la règle Aucun niveau d'accès jamais élevé dans Règles de reclassement |
|
4 |
L’utilisateur ACASE obtient l’accès complet |
Le document n'est ni restreint ni sécurisé, et ACASE y a un accès explicite. |
L'accès d'ACASE sur le document est écrasé par Accès complet. |
Mise à jour autorisée. |
Retrait d'un utilisateur d'un conteneur
L'exemple suivant explique les résultats d'une proposition de modification sur la suppression d'un utilisateur existant d'un espace de travail ou d'un répertoire.
Dans cet exemple, une proposition de reclassement de sécurité est faite pour retirer un utilisateur d'un conteneur avec une sécurité par défaut sur Public (Cas 2). L'utilisateur est supprimé car aucune autre règle de reclassement n'interdit cette modification.
|
Cas |
État proposé par |
État actuel du document |
Résultat |
Règle associée |
|
1a |
L'utilisateur ACASE est supprimé. |
Le document est sécurisé avec l'utilisateur ACASE ayant l’accès en lecture/écriture et le document sécurisé reclassé est Non |
Aucune modification. |
Document sécurisé. |
|
1b |
L'utilisateur ACASE est supprimé. |
Le document est sécurisé avec l'utilisateur ACASE ayant l’accès en lecture/écriture et le document sécurisé reclassé est Oui |
L'utilisateur ACASE est supprimé. |
Mise à jour autorisée. Voir le document sécurisé. |
|
2 |
L'utilisateur ACASE est supprimé. |
Le document n'est ni restreint ni sécurisé, et l'utilisateur ACASE n'a aucun accès. |
L'utilisateur ACASE est supprimé. Notez que l'utilisateur ACASE peut modifier des documents car la sécurité par défaut est sur Public et l'utilisateur ACASE n'a pas de restrictions supplémentaires.
Lors d'un reclassement de documents en raison d'une modification de sécurité, c'est le seul cas où un utilisateur n’ayant aucun accès est modifié. |
Mise à jour autorisée. |
|
3 |
L'utilisateur ACASE est supprimé. |
Le document n'est ni restreint ni sécurisé, et l'utilisateur ACASE a un accès complet. |
L'utilisateur ACASE est supprimé. Notez que l'utilisateur ACASE a maintenant un accès basé sur la sécurité par défaut du document. Comme le document n'est pas restreint ou sécurisé, la sécurité par défaut ne peut être que sur Public ou Aperçu. |
Mise à jour autorisée.
|
Déplacement d'un répertoire vers un nouvel emplacement
L'exemple suivant explique les résultats d'une modification proposée lors du déplacement d'un répertoire vers un nouvel emplacement. Le scénario illustre les changements de reclassement lorsqu'un répertoire, avec ses enfants (documents et répertoires), est déplacé directement vers un autre répertoire, un espace de travail, dont la sécurité par défaut est sur Public et qui a deux utilisateurs explicitement assignés.
Lors du déplacement de répertoires, le paramètre de sécurité par défaut du répertoire est essentiel pour déterminer si un événement de reclassement se produit.
Si la sécurité par défaut du répertoire est définie sur Hériter, alors le service de reclassement reclasse les éléments subordonnés selon les règles de reclassement standard.
Si la sécurité par défaut du répertoire n'est pas définie sur Hériter, on s'attend à ce que les propriétaires du répertoire veuillent maintenir manuellement la sécurité du répertoire. Par conséquent, aucun événement de reclassement ne se produit après le déplacement du répertoire. Si l'intention est de reclasser le répertoire, sa sécurité doit être changée pour Hériter après le déplacement du nouvel emplacement.
Par exemple, si une modification est effectuée en déplaçant un répertoire et son contenu (dans ce cas des documents et un répertoire) vers un nouvel emplacement de répertoire, la sécurité par défaut des documents tente de correspondre au nouveau répertoire parent. Dans cet exemple, le répertoire parent (un répertoire d'espace de travail) a une sécurité par défaut sur Public et les utilisateurs KTHOMPSON et BDYSTRA ont tous deux un accès complet.
|
Cas |
État actuel de l’élément |
Résultat attendu |
Règle associée |
|
répertoires divers |
La sécurité par défaut est réglée sur Hériter. |
Aucune modification. |
(Pas applicable) |
|
Document n°123 |
La sécurité par défaut est réglée sur Aperçu. |
Si la sécurité par défaut est modifiée sur Public, les utilisateurs suivants reçoivent une assignation : KTHOMPSON a un Accès complet BDYSTRA a un Accès complet JFALAT dispose d'un accès accordé par la sécurité par défaut sur Public. L'accès de FROTHGANGER et ACASE se réduit à la lecture/écriture avec la sécurité par défaut sur Public. |
Appliquer la sécurité par défaut du nouveau parent. La sécurité par défaut actuelle et les listes de contrôle d’accès sont supprimées, puis les listes de contrôle d’accès de sécurité par défaut du nouveau parent sont appliquées. Cela peut éventuellement modifier le niveau d'accès de certains utilisateurs. Voir la sécurité par défaut du conteneur définie sur Hériter dans Règles de reclassement |
|
Document n°899 |
Le document est restreint. |
Aucune modification. |
Les éléments restreints ne sont pas reclassés. |
|
Document n°1352 |
Le document est sécurisé et le document sécurisé reclassé est Non |
Aucune modification. |
Document sécurisé. |
|
Document n°1352 |
Le document est sécurisé et le document sécurisé reclassé est Oui |
Si la sécurité par défaut est réglée sur Public, les utilisateurs suivants reçoivent une assignation : KTHOMPSON a un Accès complet BDYSTRA a un Accès complet L'accès de FROTHGANGER et ACASE se réduit à la lecture/écriture avec la sécurité par défaut sur Public. |
Mise à jour autorisée. Voir le document sécurisé. |
|
répertoire des notes de l'avocat |
La sécurité par défaut n’est pas réglée sur Hériter. |
Aucune modification. |
Les éléments qui n'héritent pas de la sécurité ne sont pas traités. |
Déplacement d'un document vers un emplacement qui hérite de la sécurité
Le cas suivant explique les résultats d'une modification proposée lorsqu'un document est déplacé dans un répertoire. Ce scénario illustre le cas où les documents, et non le répertoire parent, sont déplacés directement vers un autre répertoire dont la sécurité par défaut est Hériter. Cela signifie que le répertoire est traité comme s'il avait la sécurité par défaut de son parent, l'espace de travail.
Lors du déplacement de documents vers un nouveau répertoire, l'intention est d'aligner la sécurité des documents avec celle du nouveau répertoire. Les documents restreints ne sont jamais modifiés, et les documents sécurisés peuvent être modifiés en fonction du paramètre Document sécurisé reclassé.
Par exemple, si une modification est effectuée en déplaçant des documents vers un nouvel emplacement de répertoire, la sécurité par défaut des documents tente de correspondre au nouveau répertoire parent. Dans cet exemple, le répertoire parent (un répertoire d'espace de travail) a une sécurité par défaut sur Public et les utilisateurs KTHOMPSON et BDYSTRA ont tous deux un accès complet.
|
Cas |
État actuel du document |
Résultat attendu |
Règle associée |
|
Document n°123 |
Le document n'est ni restreint ni sécurisé donc il est reclassé. |
Si la sécurité par défaut du document est modifiée sur Public , les utilisateurs suivants reçoivent une assignation : L’utilisateur KTHOMPSON a un Accès complet L’utilisateur BDYSTRA a un Accès complet De plus, ACASE et FROTHGANGER n'ont plus un accès complet à la lecture/écriture parce qu'ils ont été supprimés des listes de contrôle d’accès. JFALAT obtient un accès puisqu'il est retiré des listes de contrôle d’accès. Les trois utilisateurs reçoivent un accès en lecture/écriture à partir du paramètre de sécurité par défaut sur Public. |
Appliquer la sécurité par défaut du nouveau parent. La sécurité par défaut actuelle et les listes de contrôle d’accès sont supprimées, puis le conteneur ou le document hérite de la sécurité et des listes de contrôle d’accès par défaut du parent. Cela peut éventuellement modifier le niveau d'accès de certains utilisateurs. Voir la sécurité par défaut du conteneur définie sur Hériter dans Règles de reclassement. |
|
Document n°899 |
Le document est restreint. |
Aucune modification. |
Les éléments restreints ne sont pas reclassés. |
|
Document n°1352 |
Le document est sécurisé et le document sécurisé reclassé est Non |
Aucune modification. |
Document sécurisé. |
|
Document n°1352 |
Le document est sécurisé et le document sécurisé reclassé est Oui |
Si la sécurité par défaut du document est modifiée sur Public , les utilisateurs suivants reçoivent une assignation : L’utilisateur KTHOMPSON a un Accès complet L’utilisateur DYSTRA a un Accès complet De plus, ACASE et FROTHGANGER n'ont plus un accès complet à la lecture/écriture parce qu'ils ont été supprimés des listes de contrôle d’accès. Ils reçoivent un accès en lecture/écriture à partir du paramètre de sécurité par défaut sur Public. |
Document sécurisé. Mise à jour autorisée. |
Déplacement de documents vers un nouveau répertoire avec une sécurité explicite
Le cas suivant explique les résultats d'une modification proposée pour déplacer des documents dans un répertoire. Ce scénario illustre le cas où les documents, et non le répertoire parent, sont déplacés directement vers un autre répertoire dont la sécurité par défaut est Privé (soit restreint, soit, dans ce cas, sécurisé).
Lors du déplacement de documents vers un répertoire dont la sécurité est explicite, c'est-à-dire où la sécurité par défaut est définie sur Public, Privé ou Aperçu, la sécurité des documents est alignée sur le répertoire parent. Les documents restreints ne sont jamais modifiés, et les documents sécurisés peuvent être modifiés en fonction du paramètre Document sécurisé reclassé.
Dans cet exemple, le répertoire parent a une sécurité par défaut sur Privé et les utilisateurs KTHOMPSON et BDYSTRA ont tous deux un accès complet. Un événement de reclassement descendant typique, c'est-à-dire lorsque le reclassement tente de passer d'un répertoire parent à un répertoire enfant, s'arrête au premier répertoire privé qu'il rencontre (le répertoire nommé Informations confidentielles) et ne tente pas d'effectuer un reclassement de sécurité sur son contenu. Toutefois, dans ce cas, les documents sont déplacés à l'intérieur d'un répertoire de sorte que ces documents sont impliqués dans un événement de reclassement de sécurité. Cet événement commence avec les documents et non le répertoire parent, et tente de faire partie intégrante de la sécurité par défaut du parent.
Si le déplacement implique un répertoire avec les documents, ce répertoire est sujet à des règles de reclassement.
|
Cas |
État actuel du document |
Résultat attendu |
Règle associée |
|
Document n°123 |
Le document n'est ni restreint ni sécurisé donc il est reclassé. |
La sécurité par défaut est réglée sur Privé , et les utilisateurs suivants reçoivent une assignation : KTHOMPSON n’a aucun accès
BDYSTRA a un Accès complet
|
Appliquer la sécurité par défaut du nouveau parent. La sécurité par défaut actuelle et les listes de contrôle d’accès sont supprimées, puis le conteneur ou le document hérite de la sécurité et des listes de contrôle d’accès par défaut du parent. Cela modifie éventuellement le niveau d'accès de certains utilisateurs. Voir la sécurité par défaut du conteneur définie sur Hériter dans Règles de reclassement. Tous les utilisateurs ont eu les listes de contrôle d’accès supprimées
Les utilisateurs KTHOMPSON et BDYKSTRA héritent des listes de contrôle d’accès du parent. |
|
Document n°899 |
Le document est restreint. |
Aucune modification. |
Les éléments restreints ne sont pas reclassés. |
|
Document n°1352 |
Le document est sécurisé et le document sécurisé reclassé est Non |
Aucune modification. |
Document sécurisé. |
|
Document n°1352 |
Le document est sécurisé et le document sécurisé reclassé est Non |
Si la sécurité par défaut du document est modifiée sur Privé, les utilisateurs suivants reçoivent une assignation : L’utilisateur KTHOMPSON a un Accès complet L’utilisateur DYSTRA a un Accès complet De plus, ACASE et FROTHGANGER perdent maintenant leur accès parce qu'ils sont retirés des listes de contrôle d’accès. |
Document sécurisé. Mise à jour autorisée. |