Exigences obligatoires du MoReq2/Chapitre 4 : Contrôles et sécurité
De Maarch MoReq2.
- Ch. 3 : Plan de classement
- Ch. 4 : Sécurité
- Ch. 5 : Conservation et destruction
- Ch. 6 : Capture
- Ch. 7 : Identification
- Ch. 8 : Recherche et restitution
- Ch. 9 : Administration
- Ch. 11 : Non fonctionnel
- Ch. 12 : Métadonnées
Complet
Liste
| Accès | Historique des événements | Sauvegarde et restauration | Documents vitaux | ||
|---|---|---|---|---|---|
Également :
Conventions de lecture
- Les numéros d'exigence en gras dans la liste et en rouge dans le détail indiquent des exigences retenues par M.-A. Chabin.
- Les phrases en italique dans la colonne Observations sont les commentaires extraits directement du MoReq2.
- Les phrases en bleu dans la colonne Observations sont des commentaires, des réflexions ou des questions de l'équipe projet MoReq2.Maarch.
- Les liens sur la qualité des tests (O, N ou P) permettent d'accéder à ceux-ci.
Accès
Complet
Citation de l'introduction du chapitre 4.1. Accès : Parfois, les autorisations d’accès au SAE sont entièrement gérées par le SAE. D’autres fois, certaines autorisations sont gérées par un logiciel externe, tel qu’un gestionnaire de réseau. Les deux sont compatibles avec les exigences ci-après.
Dans les tableaux, lire :
| Exigence : Texte de l'exigence | Test : N (non testable)/P (partiellement testable) / O (testable) | Observations : Observations éventuelles |
|---|
4.1.1
| Le SAE doit interdire à toute personne d’effectuer quelque action que ce soit dans le SAE à moins d’y être dûment autorisée et après s’être identifiée et authentifiée.
MoReq2 ne précise pas la nature du mécanisme d’authentification. Le plus souvent, un identifiant utilisateur et un mot de passe constitueront un mécanisme d’authentification suffisant. Les entreprises/organisations utilisant MoReq2 pour un cahier des charges s’assureront que celui-ci inclut un niveau d’authentification approprié. | O |
|
4.1.2
| Le SAE doit permettre aux administrateurs d’accorder l’accès aux documents, sous-dossiers, dossiers, séries et métadonnées à des utilisateurs, profils et/ou groupes donnés et pour une période donnée. | O |
Les éléments essentiels sont la granularité et le critère temporel. Ils auraient mérités d'être distingués (voir la 4.1.4). L'accès se détermine donc par :
|
4.1.3
| Le SAE ne doit pas limiter le nombre des profils configurables. | P |
Candidat pour la catégorie des « truismes ». |
4.1.4
| Le SAE doit permettre aux administrateurs de gérer les autorisations pour l’ensemble des profils et groupes. Ces autorisations précisent les fonctionnalités, les métadonnées, les documents ou dossiers auxquels les profils et groupes ont accès, ainsi que les types d’accès. | O |
Remarquer que cette exigence est à la fois redondante avec la 4.1.2 et limitative par rapport à celle-ci : pas de gestion par utilisateur, pas de gestion temporelle. Il pourrait être déduit que la 4.1.2 est une « précision temporelle » de cette exigence et que celle-ci représente un « cas général ». Noter que les sous-dossiers et volumes sont systématiquement omis de la gestion des accès, ce qui impliquerait que l'accès à ceux-ci est directement hérité de leur dossier père. |
4.1.5
Le SAE doit proposer aux administrateurs des autorisations pour :
| P | L’attribution des autorisations d’accès devrait se conformer à la politique de sécurité.
Le niveau de granularité requis est indiqué en 13.4. Mériterait d'être scindée en plusieurs sous-exigences, à défaut d'avoir une exigence « généralisée ». La restriction d'accès selon les niveaux d'habilitation est reçue dans la catégorie : « Ça va sans dire mais ça va mieux en le disant. » C'est totalement redondant avec les 4.1.2 et 4.1.4. Pour rétablir le sens, il est possible de comprendre :
|
4.1.7
| Le SAE doit permettre aux administrateurs d’ajouter ou de retirer des utilisateurs à un profil ou un groupe à tout moment. | O | On peut admettre que les administrateurs gèrent les groupes au moyen d’une solution de gestion d’annuaire séparée. |
4.1.8
| Le SAE doit permettre l’attribution à différents administrateurs de droits sur des différentes parties du plan de classement. | O | Voir par exemple le modèle de contrôle d’accès en 13.4.
Ce qu'autorisent les 4.1.2 et 4.1.5 permet de répondre à cette exigence, celle-ci ne faisant qu'en retenir l'aspect « administrateur/administration ». |
4.1.9
| Le SAE doit permettre à un administrateur de marquer un utilisateur comme inactif sans le supprimer du système. | O | On peut admettre que les administrateurs gèrent les utilisateurs au moyen d’une solution de gestion d’annuaire séparée.
Le commentaire peut s'appliquer à l'ensemble du chapitre, pas seulement à cette exigence. En revanche, cela serait dangereux de définir que l'inactivité d'un utilisateur dans le SAE soit spécifiée dans un annuaire externe. En effet, cela impliquerait que pour pouvoir inactiver l'utilisateur dans le SAE celui-ci n'aurait plus aucun des accès dépendant de l'annuaire en question. La bonne pratique voudrait au contraire de séparer les deux, ce qui n'empêcherait pas d'inactiver un utilisateur au niveau de l'annuaire. |
4.1.10
| Le SAE doit permettre aux administrateurs de définir les mêmes droits d’accès pour les profils et pour les utilisateurs. | O | Cette fonction permet aux administrateurs de gérer un nombre limité de droits d’accès plutôt qu’un grand nombre d’utilisateurs individuels. Exemples de profils : manager, gestionnaire de plaintes, analyste financier, administrateur de base de données.
|
4.1.11
| Le SAE doit pouvoir sélectionner les droits d’accès selon les profils d’accès. | O | Voir les exemples en 13.4.
Il est légitime de se demander à quoi serviraient les profils dans le cas contraire. N'est-ce pas ce qu'impliquent les 4.1.1, 4.1.2 et 4.1.5 ? |
4.1.12
| Le SAE doit autoriser un administrateur à créer et à gérer un groupe d’utilisateurs. | O | Exemples de groupes : Ressources humaines, équipe de vente Nord.
|
4.1.13
| Le SAE doit permettre qu’un utilisateur soit membre de plusieurs groupes. | O | Certains utilisateurs pourront avoir des exigences d’accès différentes pour différentes parties du plan de classement. En tout état de cause, les droits seront accordés aux groupes en fonction des besoins métier et des politiques.
|
4.1.14
| Le SAE doit permettre aux administrateurs de créer des listes d’utilisateurs ad hoc pour le contrôle d’accès à tel ou tel sous-ensemble du plan de classement. | O |
N'est-ce pas redondant avec la 4.1.8 ? car des « utilisateurs » qui prennent le contrôle du contrôle d'accès deviennent de facto des « administrateurs ». |
4.1.15
| Le SAE doit réserver les fonctions système et les actions associées aux seuls administrateurs. | O | Ceci a pour but de préserver la valeur probante des documents électroniques archivés.
Définition des « fonctions système et actions associées » ? On supposera qu'il s'agit des fonctions d'administration. |
4.1.16
| Le SAE doit réserver aux administrateurs le droit de créer des rôles d’utilisateur et d’affecter des utilisateurs à des groupes et des profils. | O | Voir aussi section 13.4
Quelle est la plus-value de cette exigence par rapport à la 4.1.7 ? Voir encore la 4.1.18. |
4.1.17
| Le SAE doit autoriser les propriétaires des documents à préciser quels autres utilisateurs ou groupes peuvent accéder aux documents archivés. | O | Pour le sens de « propriétaire » dans MoReq2, voir le glossaire. Les propriétaires devraient logiquement être des administrateurs.
|
4.1.18
| Le SAE doit réserver aux administrateurs le droit d’opérer des modifications (addition, correction et suppression) dans les rôles pour les groupes, les profils ou les utilisateurs. | O | Ceci inclut les attributs tels que droits d’accès, privilèges, attribution de mot de passe et gestion.
Quelle est la plus-value de cette exigence par rapport à la 4.1.7 et la 4.1.16 ? Modifier une source (groupe, profil ou utilisateur) revient à lui affecter un groupe et/ou un profil différent (4.1.16). |
4.1.19
| Le SAE doit permettre aux administrateurs de créer des règles pour gérer l’accès des utilisateurs au SAE, de manière à ce que différents profils aient accès à différentes combinaisons de fonctions. Le SAE doit permettre que ces règles soient créées avec une granularité (niveau de détail) au moins égale à celle de la table des droits d’accès de la section 13.4. | O | Les entreprises/organisations n’ont pas toutes les mêmes exigences de contrôle d’accès. Il n’est donc pas pertinent de vouloir définir un modèle générique. C’est pourquoi, cette exigence se limite au niveau de détail du contrôle qu’un SAE doit offrir.
Il existe ici deux exigences distinctes :
|
4.1.20
| Le SAE doit permettre aux administrateurs de créer des profils supplémentaires à ceux du tableau en 13.4. | O | On peut envisager de définir des profils avec des droits d’accès spécifiques, par exemple : manager, gestionnaire, etc.
|
4.1.22
| Si un utilisateur effectue une recherche portant sur des contenus (par exemple recherche en plein texte ou en texte libre), le SAE doit exclure de la liste des résultats tout document archivé pour lequel l’utilisateur n’a pas les droits. | O | Cette exigence vise à éviter que des utilisateurs recourent aux fonctions de recherche de contenu pour accéder à des documents auxquels ils n’ont pas droit.
On aurait pu dire : « [...] le SAE doit n'afficher que les documents pour lesquels l'utilisateur a les droits. » Cela veut-il dire que les administrateurs ont accès à tout ? Voir également la 4.1.23. |
4.1.23
Si un utilisateur par ses requêtes ou en navigant, sans rechercher un contenu précis, tente d’accéder à un objet quelconque (document, volume, sous-dossier, dossier ou série) auquel il n’a pas le droit d’accéder, le SAE doit fournir une des réponses suivantes (à sélectionner lors de la configuration) :
La première option rejoint l’exigence relative aux résultats de recherche de contenu (voir 4.1.22). Les trois autres offrent une alternative qui peut convenir dans certains cas ; elles sont présentées ici dans un ordre de sécurité décroissant. Elles devront être configurées par un administrateur. Cette exigence ne s’applique qu’aux tentatives d’accès sans recherche de contenu. Les recherches sur le contenu des documents archivés sont traitées par l’exigence 4.1.22, à rapprocher de celle-ci. | O |
Historique des événements
Complet
Dans les tableaux, lire :
| Exigence : Texte de l'exigence | Test : N (non testable)/P (partiellement testable) / O (testable) | Observations : Observations éventuelles |
|---|
4.2.1
Le SAE doit contenir un historique des événements inaltérable capable de capturer et de stocker automatiquement l’information relative à :
| O | À titre d’illustration, les opérations enregistrées dans l’historique comprennent (liste non limitative) :
Le terme « inaltérable » signifie ici qu’il doit être impossible à tout utilisateur ou administrateur de modifier ou de supprimer tout ou partie de l’historique. Le niveau de contrôle requis dépend de l’entreprise/organisation ; le niveau de contrôle effectif dépendra du niveau de sécurité du système d’exploitation concerné et de la couche logicielle. L’historique des événements peut faire l’objet d’une ré-organisation et/ou d’une recopie dans un support de stockage hors-ligne, si le logiciel l’impose, dès lors que son intégrité est respectée.
|
4.2.2
| Quand le SAE opère le transfert des données d’historique vers un stockage hors-ligne, il doit inclure des processus sécurisés pour la gestion des données hors-ligne et spécifier le processus de rapatriement de ces données en ligne en cas de besoin ; le système doit en outre s’assurer que ce mécanisme ne peut pas être utilisé pour contourner les contrôles du SAE (par exemple, en exportant simplement les données de l’historique hors du SAE pour les modifier ou les supprimer à l’extérieur du système). | O |
|
4.2.4
| Le paramétrage de l’historique des événements doit permettre aux administrateurs de configurer les opérations à enregistrer automatiquement. | O |
|
4.2.5
| Toute modification des paramètres de l’historique doit être tracée dans l’historique. | O | Il devrait être impossible de supprimer la trace des modifications des paramètres de l’historique sans que le SAE enregistre dans l’historique qui les a modifiés et quand.
|
4.2.6
| Dès que les paramètres de l’historique ont été définis, le SAE doit tracer les opérations automatiquement et conserver ces informations dans l’historique. | O |
Catégorie : « Ça va sans dire mais ça va mieux en le disant. » |
4.2.7
| Le SAE doit conserver l’historique aussi longtemps que l’exige la politique d’archivage de l’entreprise/organisation. | N | Ce sera en principe au moins la durée de vie des documents archivés. Mais d’autres procédures peuvent s’appliquer, par exemple, après un audit périodique, l’historique des événements est détruit et remplacé par un certificat d’audit.
|
4.2.8
| Le SAE doit consigner dans un historique toutes les opérations effectuées, individuellement ou par lot, sur les documents archivés, volumes, sous-dossiers, dossiers, séries et règles de conservation/destruction. | P |
Cela n'est-il pas inclus dans la 4.2.1 ? Cela le mériterait, en tout cas. |
4.2.9
| Le SAE doit consigner dans un historique toute modification des valeurs des métadonnées énumérées dans le modèle de métadonnées de MoReq2. | P |
C'est le 7e point de la 4.2.1. |
4.2.10
| Toute annotation ou correction portée à un document archivé doit être enregistrée dans l’historique du document. | O |
|
4.2.11
| Le SAE doit automatiquement consigner dans un historique toute modification apportée aux paramètres d’administration. | O | Par exemple, si un administrateur change les autorisations d’accès d’un utilisateur ou reconfigure l’historique.
Cela ressemble à s'y méprendre aux points suivants de la 4.2.1 :
|
4.2.12
| Le SAE doit garantir que les données d’historique sont disponibles en cas d’inspection, afin qu’un événement particulier puisse être identifié et que les données associées soient accessibles. | O |
|
4.2.13
| Le SAE doit inclure des fonctions qui permettent aux utilisateurs habilités, même peu familiers du système, de rechercher des informations dans l’historique. | P | C’est une facilité de fonctionnement. Les utilisateurs peuvent être extérieurs, par exemple des auditeurs externes. Mais, pour le SAE, ce sont des utilisateurs.
Il est étonnant de préciser ici « utilisateurs habilités », car l'exigence 4.1.1 associée à la 4.1.19 garantissent que toute action dans le SAE ne peut être accomplie que par un « utilisateur habilité », quel que soit sont profil. |
4.2.14
| Le SAE doit permettre aux utilisateurs de rechercher dans l’historique la trace d’événements particuliers, d’objets (séries, documents, etc.), d’utilisateurs, groupes ou profils, de dates ou périodes de temps. | O |
La différence avec la précédente exigence est extrêmement subtile... |
4.2.15
| Le SAE doit être capable d’exporter les données d’historique de documents, volumes, sous-dossiers, dossiers et séries, sans modifier cet historique dans le SAE d’aucune façon sauf pour y ajouter l’historique de l’export. | O | Cette fonctionnalité doit par exemple permettre aux auditeurs externes d’examiner ou d’analyser l’activité du système.
|
4.2.16
| Le SAE doit être capable de capturer et de stocker, le cas échéant, toute violation aux mécanismes de contrôle d’accès (tentative d’accès à un document, un volume, sous-dossier ou dossier par un utilisateur qui n’en a pas le droit). | O | Voir en 4.1.23 des exemples de ces tentatives de violation. Ceci est sans objet quand le système est configuré pour cacher à l’utilisateur les informations pour lesquelles il n’a pas les droits.
|
Sauvegarde et restauration
Complet
Voir également la 4.4.2.
Dans les tableaux, lire :
| Exigence : Texte de l'exigence | Test : N (non testable)/P (partiellement testable) / O (testable) | Observations : Observations éventuelles |
|---|
4.3.1
| Le SAE doit fournir ou permettre des procédures de sauvegarde et de restauration automatiques pour une sauvegarde régulière de tout ou partie des séries, dossiers, documents, métadonnées, paramètres d’administration, et historique du SAE ; ainsi que leur restauration si nécessaire. | O |
Sauvegarde = Export + historique + zip ? + chiffrement ? |
4.3.2
Le SAE doit permettre à l’administrateur de programmer des sauvegardes :
| O |
|
4.3.3
| Le SAE doit réserver aux seuls administrateurs autorisés la possibilité d’effectuer des restaurations à partir des sauvegardes. | O |
Rapporté aux précédentes, cela sous-entend que tous les administrateurs peuvent programmer des sauvegardes. |
4.3.4
| Quand un SAE opère une restauration à partir d’une sauvegarde, l’intégrité des données et de l’historique des événements doit être préservée. | O | Les documents archivés dûment détruits mais encore présents dans la sauvegarde ne doivent pas être restaurés, sauf cas exceptionnel.
L'exigence est couverte par celle de l'intégrité de l'export, sauf pour l'historique et pour les documents objets du commentaire. |
4.3.5
| Si le SAE prévoit des points de contrôle et des moyens de restauration progressive, le SAE doit réserver aux seuls administrateurs autorisés le droit de le faire. | O |
La 4.3.3 couvrant l'accès à la fonctionnalité de restauration, cette exigence, qui n'a pour objet qu'une succession de restaurations, est également couverte. |
Documents vitaux
Complet
Dans les tableaux, lire :
| Exigence : Texte de l'exigence | Test : N (non testable)/P (partiellement testable) / O (testable) | Observations : Observations éventuelles |
|---|
4.4.1
| Le SAE doit permettre aux administrateurs de signaler tels et tels dossiers ou documents comme étant ou contenant des « documents vitaux ». | O | Cette information devrait figurer en tant que métadonnée.
Dans le modèle de métadonnées, les sous-dossier et volume n'ont pas cette métadonnée, alors qu'ils peuvent participer du lien entre le document et le dossier. |
4.4.2
Le SAE doit pouvoir effectuer deux opérations de sauvegarde distinctes :
| O | On distingue deux opérations de sauvegarde pour les raisons suivantes :
Cela permet aussi une meilleure gestion des restaurations du SAE car les restaurations « vitales » peuvent être indépendantes et intervenir à un autre moment que les restaurations « intégrales ». La section 4.3 précise que les sauvegardes peuvent être effectuées soit par le SAE soit par le biais d’un autre outil. Voir également la 4.4.4. |
4.4.3
| Après une restauration « vitale », le SAE doit être totalement opérationnel. | P | Après une restauration « vitale », il manquera de nombreux dossiers et documents. Malgré tout, le SAE ne doit aucunement être limité dans son fonctionnement et dans les services rendus aux utilisateurs.
Cela implique que dans la « sauvegarde vitale » il y a également les utilisateurs, profils et groupes qui peuvent y avoir accès, ainsi que toutes les règles de conservation/destruction associées. |
4.4.5
| Le SAE doit permettre aux administrateurs d’indiquer que tels ou tels dossiers ou documents archivés ne sont plus vitaux. Cette action doit être tracée dans l’historique. | O | Par exemple, un bail ou un contrat peuvent arriver à expiration et dès lors perdre leur caractère vital.
|
