Jusqu'à présent, ce document a traité de la gestion de solutions Oracle Hierarchical Storage Manager et StorageTek QFS Software en tant que systèmes de fichiers UNIX ordinaires où des utilisateurs et des applications créent, modifient et suppriment régulièrement des fichiers. L'accent portait sur le cache disque, l'archive servant principalement de service de sauvegarde hautement intégré. Ce chapitre s'intéresse à l'archive en tant que solution de référentiel et de gestion pour la conservation à long terme des données. Les principes et techniques de gestion décrites précédemment restent valables. Simplement, le cache disque devient essentiellement un moyen d'intégrer des fichiers dans une archive où ils ne pourront plus être supprimés ni modifiés.
Les besoins précis sont variables. Un référentiel qui conserve des dossiers comptables ou médicaux pendant une période fixée par la loi va probablement nécessiter des suppressions périodiques. En revanche, une archive contenant des données scientifiques, historiques ou généalogiques, ou encore des enregistrements numériques de musique, de films ou de programmes de télévision, risque fort d'être vouée à conserver ces contenus indéfiniment. C'est pourquoi Oracle HSM prend en charge la préservation numérique de plusieurs manières :
Les synthèses de message (sommes de contrôle) permettent de détecter l'altération ou la corruption des données et les modifications de fichier non autorisées, ce qui permet de résoudre les problèmes matériels et de remplacer les fichiers détériorés par des copies saines stockées ailleurs dans l'archive.
Les attributs d'immuabilité des fichiers fonctionnent de concert avec les synthèses de message pour garantir que seul le superutilisateur peut intervenir sur les fichiers qui ont été rendus immuables. Chaque fois que Oracle HSM transfère ou archive un fichier considéré comme immuable, une somme de contrôle est revalidée et stockée avec l'attribut d'immuabilité pour prouver que le fichier reste inchangé.
Les systèmes de fichiers WORM (Write Once Read Many) d'Oracle HSM vous permettent de rendre des fichiers accessibles en lecture seule et d'imposer leur conservation pendant une période spécifiée. Ces systèmes de fichiers peuvent être configurés de telle sorte que le superutilisateur ne puisse pas modifier les fichiers ni leurs attributs (notamment l'attribut d'immuabilité évoqué plus haut).
Ce chapitre commence par récapituler brièvement les mesures de protection des données fournies par Oracle HSM qui constituent le fondement de toute solution de stockage à long terme : Configuration des systèmes de fichiers aux fins de préservation. Il présente ensuite les tâches plus précisément liées à la préservation des données :
Toute solution de préservation s'appuie sur l'existence de systèmes de fichiers présentant un niveau élevé d'intégrité et de redondance. Au besoin, reportez-vous aux chapitres traitant de l'implémentation dans le document Guide d'installation et de configuration d'Oracle Hierarchical Storage Manager et StorageTek QFS. Protégez l'accès à l'archive en assurant la redondance des serveurs, des connexions réseau et des périphériques de stockage. Protégez les données des fichiers en configurant au moins deux copies supplémentaires de chaque fichier et en les stockant sur des médias indépendants. Dans la plupart des cas, l'idéal consiste à archiver une copie sur un disque ou un disque dur électronique (SSD) et deux copies sur bande. Si possible, assurez-vous que les blocs sur bande sont écrits et lus correctement en implémentant la fonctionnalité de vérification d'intégrité des données d'Oracle HSM. Protégez les métadonnées du système de fichiers en générant régulièrement des fichiers dump et en sauvegardant périodiquement les journaux d'archivage.
Les synthèses (sommes de contrôle) de message permettent aux responsables de la préservation des données de tester les fichiers archivés pour vérifier l'existence de modifications susceptibles d'indiquer une détérioration graduelle, une erreur liée au matériel ou à l'opérateur, voire des dommages causés délibérément et sans autorisation au contenu. Une synthèse de message est un simple résumé mathématique du contenu d'un message, généré par une fonction de hachage cryptographique unidirectionnelle. Les fonctions de hachage cryptographique sont extrêmement sensibles aux modifications des données d'entrée. Le moindre changement en entrée peut produire des changements énormes en sortie. C'est pourquoi les synthèses de message constituent un moyen idéal pour détecter les corruptions et les modifications non autorisées de fichiers. En recalculant la synthèse d'un fichier et en comparant le résultat à une valeur de synthèse stockée préalablement, vous pouvez savoir si le fichier a subi des modifications.
Les systèmes de fichiers Oracle Hierarchical Storage Manager peuvent ingérer, créer, stocker et valider des synthèses de message à l'aide des fonctions de hachage cryptographique suivantes :
SHA1 - membre 160 bits de la famille SHA (Secure Hash Algorithm) de fonctions cryptographiques
Les algorithmes de hachage SHA sont définis par le NIST (National Institute of Standards and Technology) dans le document Federal Information Processing Standard (FIPS) Publication 180-4 (2012). Oracle HSM utilise par défaut SHA1.
SHA256 - membre 256 bits de la famille d'algorithmes de hachage SHA
SHA384 - membre 384 bits de la famille d'algorithmes de hachage SHA
SHA512 - membre 512 bits de la famille d'algorithmes de hachage SHA
MD5 - fonction de synthèse de message (Message Digest) 128 bits définie par l'IETF (Internet Engineering Task Force) dans la RFC (Request for Comment) 1321
Fonction Oracle HSM 128 bits propriétaire, désormais utilisée essentiellement à des fins de compatibilité avec les implémentations antérieures de Storage Archive Manager.
Les utilisateurs peuvent fournir une valeur de synthèse existante lorsqu'un fichier est intégré dans le référentiel, ou bien ils peuvent demander au système de fichiers de calculer une nouvelle valeur de synthèse, immédiatement ou au lors du premier archivage du fichier. Les systèmes de fichiers Oracle HSM stockent ces valeurs avec leurs métadonnées, à l'aide d'un attribut de fichier spécial. Dès lors que cet attribut est défini, le système de fichiers recalcule une synthèse et la valide par rapport à la valeur stockée chaque fois que le fichier correspondant est archivé et, éventuellement, chaque fois que le fichier est transféré d'un média d'archivage vers le cache disque.
Notez toutefois que la fonctionnalité de migration de média d'Oracle HSM copie les fichiers vers le nouveau média sans recalculer la somme de contrôle. (Pour plus d'informations sur la migration entre médias, voir le Chapitre 8, Migration vers un nouveau média de stockage.) Si un fichier n'est pas copié correctement, il demeure donc une faible probabilité pour que la corruption ne soit pas détectée avant la prochaine étape de transfert et de validation de ce fichier. La fonctionnalité DIV (Data Integrity Validation) diminue ce risque (voir le document Guide d'installation et de configuration d'Oracle Hierarchical Storage Manager et StorageTek QFS pour plus de détails).
Avant de commencer à utiliser les synthèses de message, lisez et appliquez la section Vérifier les performances de l'hôte du système de fichiers. Vous pourrez ensuite vous référer aux sections suivantes pour apprendre à fournir, générer et valider des synthèses :
Fournir une synthèse de message et activer la validation pour un fichier
Générer une synthèse et activer la validation pour un fichier
Générer une synthèse et activer la validation pour chaque fichier d'un répertoire
Modifier les attributs de synthèse et de validation avant l'archivage d'un fichier
Si vous envisagez un usage intensif des synthèses de message, assurez-vous que l'hôte du système de fichiers dispose de ressources de calcul suffisantes pour garantir des performances correctes. La plupart des plates-formes récentes intègrent un équipement cryptographique dédié capable d'effectuer des calculs spécialisés sans consommer de capacités CPU. N'hésitez pas à tirer parti de ces avantages, le cas échéant.
Pour vérifier les capacités d'un hôte de système de fichiers potentiel, procédez de la manière suivante :
Connectez-vous à l'hôte du système de fichiers en tant qu'utilisateur root:
root@solaris:~#
Vérifiez que le système d'exploitation de l'hôte est Solaris 11.1 ou une version supérieure. Exécutez la commande uname -v.
Les versions antérieures du système d'exploitation ne prennent pas en charge l'accélération matérielle des fonctions de hachage. Dans l'exemple proposé, l'hôte exécute le système d'exploitation Solaris 11.2 :
root@solaris:~# uname -v 11.2 root@solaris:~#
Affichez l'architecture du jeu d'instructions. A l'invite de commande, entrez isainfo -v :
root@solaris:~# isainfo -v
Si l'hôte Solaris 11 est un système Oracle Sun SPARC T3 (ou version ultérieure), la commande isainfo -v doit renvoyer une liste de jeux d'instructions qui prennent en charge les algorithmes cryptographiques sha512, sha256, sha1 et md5.
Dans cet exemple, l'hôte Sun SPARC T4-2 fournit l'accélération matérielle pour les familles d'algorithmes SHA1, SHA2 et MD5 :
[Sun_SPARC_T4-2]root@solaris:~# isainfo -v
64-bit sparcv9 applications
crc32c cbcond pause mont mpmul sha512 sha256 sha1 md5 camellia kasumi
des aes ima hpc vis3 fmaf asi_blk_init vis2 vis popc
root@solaris:~#
Si l'hôte Solaris est un système x86/64, il prendra en charge l'accélération matérielle SHA-1 si les résultats de la commande isainfo -v comprennent le jeu d'instructions ssse3 (Supplemental Streaming SIMD Extensions 3).
Dans cet exemple, l'hôte Sun X3-2 prend en charge l'accélération matérielle des synthèses SHA-1 :
[Sun_X3-2]root@solaris:~# isainfo -v
64-bit amd64 applications
avx xsave pclmulqdq aes sse4.2 sse4.1 ssse3 popcnt tscp ahf cx16 sse3
sse2 sse fxsr mmx cmov amd_sysc cx8 tsc fpu
root@solaris:~#
Lorsque vous archivez des fichiers qui sont déjà associés à des synthèses de message, procédez de la manière suivante.
Connectez-vous à l'hôte du système de fichiers en tant qu'utilisateur root:
root@solaris:~#
A l'invite de commande, entrez ssum -a algorithm -h digest -G [-u]filename, où :
-a algorithm identifie la fonction de hachage cryptographique que le système de fichiers doit utiliser pour valider le fichier par rapport à la synthèse de message fournie.
-h digest identifie la synthèse de message que le système de fichiers doit utiliser pour valider le fichier.
-G impose une validation immédiate. Le système de fichiers affecte à l'attribut de fichier hash la valeur de la synthèse de message fournie, puis calcule de manière indépendante une nouvelle synthèse pour le fichier et compare le résultat à la valeur stockée. Si la valeur calculée est égale à la valeur fournie, le système de fichiers définit l'attribut validated pour le fichier concerné. Il définit ensuite l'attribut generate pour que la validité soit vérifiée lors de chaque archivage du fichier.
-u définit l'attribut de fichier use (facultatif). Lors de chaque transfert du fichier, le système de fichiers recalcule la synthèse de message et valide le résultat par rapport à la valeur stockée dans l'attribut hash.
filename est le chemin et le nom du fichier.
Dans cet exemple, nous fournissons une synthèse SHA256 et demandons au système de fichiers de recalculer et valider immédiatement la valeur de la synthèse du fichier data10. Lorsque nous vérifions les attributs du fichier à l'aide de la commande sls -D -h data10, nous constatons que les attributs generate et validated ont été définis, que l'attribut algorithm a pris la valeur SHA-256 et que la valeur de synthèse a été calculée et stockée dans l'attribut hash.
root@solaris:~# ssum -h f03ce01b3828...f7459503007e -a sha256 -g data10 root@solaris:~# sls -D -h data10 data10: mode: -rw-r--r-- links: 1 owner: root group: root length: 14975 admin id: 0 inode: 90217.1 project: user.root(1) access: Jul 16 16:14 modification: Jul 16 16:14 changed: Jul 16 16:15 attributes: Jul 16 16:14 creation: Jul 16 16:14 residence: Jul 16 16:14 checksum: generate validated algorithm: SHA-256 hash: f03ce01b3828...f7459503007e root@solaris:~#
Si nécessaire, modifiez le fichier de la façon habituelle.
Dans cet exemple, nous avons modifié un fichier nommé data10m depuis son dernier archivage. La commande sls -D -h permet de constater que l'indicateur d'obsolescence S (Stale) a été défini sur les deux copies ; en effet, aucune d'elles ne reflète les modifications les plus récentes. Lorsque nous vérifions la valeur de la synthèse SHA-256 pour le fichier modifié à l'aide de la commande Solaris digest, nous voyons que l'attribut hash du fichier contient aussi une valeur de synthèse périmée :
root@solaris:~# sls -D -h data10m data10m: mode: -rw-r--r-- links: 1 owner: root group: root length: 14983 admin id: 0 inode: 90307.1 project: user.root(1) copy 1: S----- Jul 17 16:47 dd.1 dk diskarchive f221 copy 2: S----- Jul 20 11:31 a8d.1 li VOL002 access: Jul 20 11:32 modification: Jul 20 11:31 changed: Jul 17 16:37 attributes: Jul 17 16:36 creation: Jul 17 16:36 residence: Jul 17 16:36 checksum: generate algorithm: SHA-256 hash: f03ce01b3828...f7459503007e root@solaris:~# digest -a sha256 data10m 56c55bb421cc...71ac2ac0b7b0 root@solaris:~#
Si nécessaire, vous pouvez modifier les attributs de synthèse d'un fichier modifié avant de l'archiver à nouveau.
Dans cet exemple, nous passons de l'algorithme de synthèse SHA256 à SHA1, avec effet immédiat :
root@solaris:~# ssum -a sha1 -G data10m root@solaris:~# sls -D -h data10m data10m: mode: -rw-r--r-- links: 1 owner: root group: root length: 14983 admin id: 0 inode: 90307.1 project: user.root(1) release -a; copy 1: S----- Jul 20 13:00 e0.1 dk diskarchive f224 copy 2: S----- Jul 20 13:05 a93.1 li VOL002 access: Jul 20 16:39 modification: Jul 20 16:39 changed: Jul 17 16:37 attributes: Jul 17 16:36 creation: Jul 17 16:36 residence: Jul 20 16:29 checksum: generate validated algorithm: SHA-1 hash: 92003525f0f8...53e29d0718c8 root@solaris:~#
Sinon, attendez que le système de fichiers archive le fichier modifié et mette à jour automatiquement ses attributs de synthèse.
Lors de l'archivage d'un fichier modifié, le système de fichiers recalcule la valeur de synthèse, place la nouvelle valeur dans l'attribut hash et définit l'indicateur d'obsolescence S pour toutes les copies archivées de versions antérieures de ce fichier. Dans cet exemple, nous avons édité le fichier data10m sans toucher aux attributs de synthèse. L'archiveur a comme prévu créé un nouvel objet copy 1 sur le disque et il a mis à jour l'attribut hash. Une copie du fichier tel qu'il était avant la modification est conservée sur bande, avec l'indicateur d'obsolescence S, jusqu'au moment où l'archiveur doit créer l'archive copy 2 :
root@solaris:~# sls -D -h data10m data10m: mode: -rw-r--r-- links: 1 owner: root group: root length: 14983 admin id: 0 inode: 90307.1 project: user.root(1) copy 1: ------ Jul 17 16:47 dd.1 dk diskarchive f221 copy 2: S----- Jul 20 11:31 a8d.1 li VOL002 access: Jul 20 11:32 modification: Jul 20 11:31 changed: Jul 17 16:37 attributes: Jul 17 16:36 creation: Jul 17 16:36 residence: Jul 17 16:36 checksum: generate algorithm: SHA-256 hash: 56c55bb421cc...71ac2ac0b7b0
Pour générer la synthèse d'un fichier et activer sa validation, procédez de la manière suivante :
Connectez-vous à l'hôte du système de fichiers en tant qu'utilisateur root:
root@solaris:~#
A l'invite de commande, entrez ssum -a algorithm -g|G [-u] filename, où :
-a algorithm indique la fonction de hachage cryptographique que le système de fichiers va utiliser pour générer la synthèse du fichier.
-g définit l'attribut generate pour le fichier concerné. Lors du premier archivage du fichier, le système de fichiers calcule une synthèse. Chaque fois que ce fichier sera à nouveau archivé, le système de fichiers va recalculer la synthèse et valider le résultat par rapport à la valeur stockée.
-G définit les attributs generate et validate pour le fichier. Le système de fichiers calcule immédiatement une synthèse et place le résultat dans l'attribut hash. Chaque fois que ce fichier sera archivé, le système de fichiers va recalculer la synthèse et valider le résultat par rapport à la valeur stockée.
-u définit l'attribut de fichier use (facultatif). Lors de chaque transfert du fichier, le système de fichiers recalcule la synthèse et valide le résultat par rapport à la valeur stockée dans l'attribut hash.
filename est le chemin et le nom du fichier.
Dans cet exemple, nous demandons au système de fichiers d'utiliser l'algorithme SHA256 pour calculer la synthèse associée au fichier data11 avant de l'archiver. Lorsque nous vérifions les attributs du fichier via la commande sls -D -h data10, nous constatons que pour chaque fichier, l'attribut generate a été activé et l'attribut algorithm a pris la valeur SHA-256. Le fichier concerné n'a pas encore été archivé, de sorte que la valeur de synthèse n'a pas été calculée et stockée dans l'attribut hash :
root@solaris:~# ssum -a sha256 -g data11 root@solaris:~# sls -D -h data11 data11: mode: -rw-r--r-- links: 1 owner: root group: root length: 14975 admin id: 0 inode: 90218.1 project: user.root(1) access: Jul 16 16:14 modification: Jul 16 16:14 changed: Jul 16 16:22 attributes: Jul 16 16:14 creation: Jul 16 16:14 residence: Jul 16 16:14 checksum: generate algorithm: SHA-256 hash: root@solaris:~#
Si nécessaire, éditez le fichier de la façon habituelle.
Dans cet exemple, nous avons modifié un fichier nommé data11m depuis son dernier archivage. La commande sls -D -h permet de constater que l'indicateur d'obsolescence S (Stale) a été défini sur les deux copies ; en effet, aucune d'elles ne reflète les modifications les plus récentes. Lorsque nous vérifions la valeur de la synthèse SHA-256 pour le fichier modifié à l'aide de la commande Solaris digest, nous voyons que l'attribut hash du fichier contient aussi une valeur de synthèse périmée :
root@solaris:~# sls -D -h data11m data11m: mode: -rw-r--r-- links: 1 owner: root group: root length: 14983 admin id: 0 inode: 90307.1 project: user.root(1) copy 1: S----- Jul 17 16:47 dd.1 dk diskarchive f221 copy 2: S----- Jul 20 11:31 a8d.1 li VOL002 access: Jul 20 11:32 modification: Jul 20 11:31 changed: Jul 17 16:37 attributes: Jul 17 16:36 creation: Jul 17 16:36 residence: Jul 17 16:36 checksum: generate algorithm: SHA-256 hash: f03ce01b3828...f7459503007e root@solaris:~# digest -a sha256 data11m 56c55bb421cc...71ac2ac0b7b0 root@solaris:~#
Si nécessaire, vous pouvez modifier les attributs de synthèse d'un fichier modifié avant de l'archiver à nouveau.
Dans cet exemple, nous passons de l'algorithme de synthèse SHA256 à SHA1, avec effet immédiat :
root@solaris:~# ssum -a sha1 -G data11m root@solaris:~# sls -D -h data11m data11m: mode: -rw-r--r-- links: 1 owner: root group: root length: 14983 admin id: 0 inode: 90307.1 project: user.root(1) release -a; copy 1: S----- Jul 20 13:00 e0.1 dk diskarchive f224 copy 2: S----- Jul 20 13:05 a93.1 li VOL002 access: Jul 20 16:39 modification: Jul 20 16:39 changed: Jul 17 16:37 attributes: Jul 17 16:36 creation: Jul 17 16:36 residence: Jul 20 16:29 checksum: generate validated algorithm: SHA-1 hash: 92003525f0f8...53e29d0718c8 root@solaris:~#
Sinon, attendez que le système de fichiers archive le fichier modifié et mette à jour automatiquement ses attributs de synthèse.
Lors de l'archivage d'un fichier modifié, le système de fichiers recalcule la valeur de synthèse, place la nouvelle valeur dans l'attribut hash et définit l'indicateur d'obsolescence S pour toutes les copies archivées de versions antérieures de ce fichier.
Dans cet exemple, nous avons édité le fichier data11m sans toucher aux attributs de synthèse. L'archiveur a comme prévu créé un nouvel objet copy 1 sur le disque et il a mis à jour l'attribut hash. Une copie du fichier tel qu'il était avant la modification est conservée sur bande, avec l'indicateur d'obsolescence S, jusqu'au moment où l'archiveur doit créer l'archive copy 2 :
root@solaris:~# sls -D -h data11m mdata11: mode: -rw-r--r-- links: 1 owner: root group: root length: 14983 admin id: 0 inode: 90307.1 project: user.root(1) copy 1: ------ Jul 17 16:47 dd.1 dk diskarchive f221 copy 2: S----- Jul 20 11:31 a8d.1 li VOL002 access: Jul 20 11:32 modification: Jul 20 11:31 changed: Jul 17 16:37 attributes: Jul 17 16:36 creation: Jul 17 16:36 residence: Jul 17 16:36 checksum: generate algorithm: SHA-256 hash: 56c55bb421cc...71ac2ac0b7b0
Pour générer une synthèse et définir les attributs de validation pour chaque fichier d'un répertoire, procédez de la manière suivante :
Connectez-vous à l'hôte du système de fichiers en tant qu'utilisateur root:
root@solaris:~#
A l'invite de commande, entrez ssum -a algorithm -g|G [-u] -r directoryname, où :
-a algorithm indique la fonction de hachage cryptographique que le système de fichiers va utiliser pour générer les synthèses.
-g active l'attribut generate pour chaque fichier. Lors du premier archivage d'un fichier, le système de fichiers calcule une synthèse pour ce fichier. Chaque fois que ce fichier sera à nouveau archivé, le système de fichiers va recalculer la synthèse et valider le résultat par rapport à la valeur stockée.
-G définit les attributs generate et validate pour chaque fichier. Le système de fichiers calcule immédiatement une synthèse et place le résultat dans l'attribut hash. Chaque fois que ce fichier sera archivé, le système de fichiers va recalculer la synthèse et valider le résultat par rapport à la valeur stockée.
-u définit l'attribut de fichier use (facultatif). Chaque fois que ce fichier sera transféré, le système de fichiers va recalculer la synthèse et valider le résultat par rapport à la valeur stockée.
-r applique la commande de manière récursive à tous les fichiers du répertoire indiqué.
directoryname indique le chemin et le nom du répertoire concerné.
Dans le premier exemple, nous demandons au système de fichiers d'utiliser l'algorithme SHA256 pour calculer la synthèse des fichiers contenus dans le répertoire datasetA avant leur archivage. Lorsque nous vérifions les attributs du fichier via la commande sls -D -h datasetA, nous constatons que pour chaque fichier, l'attribut generate a été activé et l'attribut algorithm a pris la valeur SHA-256. Les fichiers n'ayant pas encore été archivés, la valeur de synthèse n'a pas été calculée et stockée dans l'attribut hash :
root@solaris:~# ssum -a sha256 -g -r datasetA root@solaris:~# sls -D -h datasetA datasetA/pdata0: mode: -rw-r--r-- links: 1 owner: root group: root length: 14983 admin id: 0 inode: 90232.1 project: user.root(1) access: Jul 16 16:47 modification: Jul 16 16:47 changed: Jul 16 16:47 attributes: Jul 16 16:47 creation: Jul 16 16:47 residence: Jul 16 16:47 checksum: generate algorithm: SHA-256 hash: ... datasetA/pdata20: mode: -rw-r--r-- links: 1 owner: root group: root length: 14983 admin id: 0 inode: 90234.1 project: user.root(1) access: Jul 16 16:47 modification: Jul 16 16:47 changed: Jul 16 16:47 attributes: Jul 16 16:47 creation: Jul 16 16:47 residence: Jul 16 16:47 checksum: generate algorithm: SHA-256 hash: ... root@solaris:~#
Dans le deuxième exemple, nous demandons au système de fichiers d'utiliser l'algorithme SHA256 pour calculer immédiatement la synthèse correspondant aux fichiers du répertoire datasetB avant leur archivage. Lorsque nous vérifions les attributs de fichier via la commande sls -D -h datasetB, nous constatons que les attributs generate et validated ont été activés pour chaque fichier, que l'attribut algorithm a pris la valeur SHA-256 et que la valeur de synthèse a été calculée et stockée dans l'attribut hash :.
root@solaris:~# ssum -a sha256 -G -r datasetB root@solaris:~# sls -D -h datasetB datasetB/qdata0: mode: -rw-r--r-- links: 1 owner: root group: root length: 14983 admin id: 0 inode: 90232.1 project: user.root(1) access: Jul 16 16:47 modification: Jul 16 16:47 changed: Jul 16 16:47 attributes: Jul 16 16:47 creation: Jul 16 16:47 residence: Jul 16 16:47 checksum: generate validated algorithm: SHA-256 hash: 4d2800eb82b3...520341edde95 ... datasetB/qdata12: mode: -rw-r--r-- links: 1 owner: root group: root length: 14983 admin id: 0 inode: 90234.1 project: user.root(1) access: Jul 16 16:47 modification: Jul 16 16:47 changed: Jul 16 16:47 attributes: Jul 16 16:47 creation: Jul 16 16:47 residence: Jul 16 16:47 checksum: generate validated algorithm: SHA-256 hash: 5b057f1b7b48...88c590d47dec ... root@solaris:~#
Si nécessaire, vous pouvez valider un fichier avant qu'il soit transféré vers le cache disque en vue de son utilisation. La procédure est la suivante :
Connectez-vous à l'hôte du système de fichiers en tant qu'utilisateur root:
root@solaris:~#
A l'invite de commande, entrez ssum -u [-a algorithm [-h digest] -g|G] filename, où :
-u impose une validation avant le transfert en activant l'attribut de fichier use. Lorsque l'attribut use est défini pour un fichier, le système de fichiers ne va pas copier ce fichier du média d'archivage vers le cache disque tant qu'il n'a pas généré la synthèse correspondante et vérifié sa validité par rapport à la valeur stockée dans l'attribut hash du fichier.
-a algorithm, -h digest et -g|G sont des paramètres facultatifs qui définissent les attributs obligatoires algorithm, hash et generate s'ils n'ont pas été définis préalablement.
filename est le chemin et le nom du fichier.
Dans cet exemple, nous avons déjà activé la validation pour le fichier data102. Comme le montre le résultat de la commande sls -D -h data102, les attributs de fichier generateet validated ont été définis, l'attribut algorithm a pris la valeur SHA-256 et la valeur de synthèse a été calculée et placée dans l'attribut hash :
root@solaris:~# ssum -a sha256 -F data102 root@solaris:~# sls -D -h data102 data102: mode: -rw-r--r-- links: 1 owner: root group: root length: 14979 admin id: 0 inode: 90264.1 project: user.root(1) access: Jul 16 17:34 modification: Jul 16 17:34 changed: Jul 16 17:34 attributes: Jul 16 17:34 creation: Jul 16 17:34 residence: Jul 16 17:34 checksum: generate validated algorithm: SHA-256 hash: baae932ce1cf...93166a2e36b5 root@solaris:~#
Nous pouvons donc définir l'attribut use pour garantir que le fichier sera validé par le système de fichiers avant d'être transféré. La commande sls -D -h data102 permet de constater que l'attribut use est défini :
root@solaris:~# ssum -u data102 root@solaris:~# sls -D -h data102 data102: mode: -rw-r--r-- links: 1 owner: root group: root length: 14979 admin id: 0 inode: 90264.1 project: user.root(1) access: Jul 16 17:34 modification: Jul 16 17:34 changed: Jul 16 17:34 attributes: Jul 16 17:34 creation: Jul 16 17:34 residence: Jul 16 17:34 checksum: generate use validated algorithm: SHA-256 hash: baae932ce1cf...93166a2e36b5 root@solaris:~#
Si un fichier n'a pas été défini comme immutable et n'a pas encore été archivé, vous pouvez modifiez les attributs de synthétisation et de validation associés en suivant la procédure ci-après.
Connectez-vous à l'hôte du système de fichiers en tant qu'utilisateur root:
root@solaris:~#
Si nécessaire, changez d'algorithme de synthèse. A l'invite de commande, entrez ssum -a newalgorithm filename, où :
-a newalgorithm indique la fonction de hachage cryptographique qui remplace l'algorithme de synthèse spécifié précédemment.
filename est le chemin et le nom du fichier.
Dans cet exemple, nos stratégies de préservation des données nécessitent la haute résistance aux collisions de l'algorithme SHA256. Pourtant, comme le montre la commande sls -D -h, nous avons par inadvertance indiqué l'algorithme SHA1 lors de la définition des attributs de synthèse du fichier data319. Comme ce fichier n'a pas encore été archivé, nous avons la possibilité de lui associer l'algorithme de hachage SHA256 :
root@solaris:~# sls -D -h data319 data319: mode: -rw-r--r-- links: 1 owner: root group: root length: 14983 admin id: 0 inode: 90301.1 project: user.root(1) access: Jul 17 15:27 modification: Jul 17 15:27 changed: Jul 17 15:28 attributes: Jul 17 15:27 creation: Jul 17 15:27 residence: Jul 17 15:27 checksum: generate algorithm: SHA-1 hash: root@solaris:~# ssum -a sha256 data319 root@solaris:~# sls -D -h data319 data319: mode: -rw-r--r-- links: 1 owner: root group: root length: 14983 admin id: 0 inode: 90301.1 project: user.root(1) access: Jul 17 15:27 modification: Jul 17 15:27 changed: Jul 17 15:28 attributes: Jul 17 15:27 creation: Jul 17 15:27 residence: Jul 17 15:27 checksum: generate algorithm: SHA-256 hash: root@solaris:~#
Si nécessaire, effacez les attributs de synthèse et restaurez les paramètres de fichier par défaut. A l'invite de commande, entrez ssum -d filename,où :
-d rétablit les valeurs par défaut des attributs de synthèse du fichier.
filename est le chemin et le nom du fichier.
Dans cet exemple, nous ne voulions pas configurer la synthèse et la validation pour le fichier data44. Pourtant, la commande sls -D -h indique que nous l'avons fait par inadvertance. Comme le fichier n'a pas encore été archivé, nous avons la possibilité d'annuler les attributs generate et use qui contrôlent la validation des synthèses lors de l'archivage et du transfert des fichiers. Les données placées dans les attributs validated, algorithm et hash sont conservées, mais elles n'affectent pas le comportement du système de fichiers :
root@solaris:~# sls -D -h data44 data44: mode: -rw-r--r-- links: 1 owner: root group: root length: 14983 admin id: 0 inode: 90292.1 project: user.root(1) access: Jul 17 14:58 modification: Jul 17 14:57 changed: Jul 17 14:58 attributes: Jul 17 14:57 creation: Jul 17 14:57 residence: Jul 17 14:57 checksum: generate use validated algorithm: SHA-256 hash: 3b4b15f8f69c...bae62c7e7568 root@solaris:~# ssum -d data44 root@solaris:~# sls -D -h data44 data44: mode: -rw-r--r-- links: 1 owner: root group: root length: 14983 admin id: 0 inode: 90292.1 project: user.root(1) access: Jul 17 14:58 modification: Jul 17 14:57 changed: Jul 17 14:58 attributes: Jul 17 14:57 creation: Jul 17 14:57 residence: Jul 17 14:57 checksum: validated algorithm: SHA-256 hash: 3b4b15f8f69c...bae62c7e7568 root@solaris:~#
Si nécessaire, réinitialisez les attributs de synthèse et de validation obligatoires avant l'archivage du fichier. A l'invite de commande, entrez ssum avec les options et le nom de fichier approprié.
Dans cet exemple, nous décidons de réactiver la synthèse de message sur le fichier qndat44 et de valider les synthèses avant l'archivage. En revanche, nous ne demandons pas de validation avant le transfert. Nous rétablissons donc l'attribut generate, mais pas l'attribut use :
root@solaris:~# ssum -g data44 root@solaris:~# sls -D -h data44 data44: mode: -rw-r--r-- links: 1 owner: root group: root length: 14983 admin id: 0 inode: 90292.1 project: user.root(1) access: Jul 17 14:58 modification: Jul 17 14:57 changed: Jul 17 14:58 attributes: Jul 17 14:57 creation: Jul 17 14:57 residence: Jul 17 14:57 checksum: generate validated algorithm: SHA-256 hash: 3b4b15f8f69c...bae62c7e7568 root@solaris:~#
Les besoins de préservation exigent souvent des mécanismes qui assurent l'immuabilité des fichiers. L'archive doit à la fois empêcher toute modification et prouver qu'aucune modification ne s'est produite. Pour garantir cette fixité, les systèmes de fichiers d'archive Oracle HSM combinent les synthèses de message et les attributs de fichier associés (évoqués plus haut) avec des attributs supplémentaires qui rendent le fichier immuable. Une fois qu'un fichier a été rendu immuable, seuls les utilisateurs dotés de privilèges de superutilisateur peuvent modifier son statut. Si vous combinez l'immuabilité avec un système de fichiers strictement WORM (Write Once Read Many), même les superutilisateurs seront dans l'incapacité d'apporter des modifications (voir Compréhension des systèmes de fichiers WORM pour plus d'informations).
Vous pouvez rendre un fichier immuable de plusieurs manières :
Fournir une synthèse de message et rendre un fichier immuable
Générer une synthèse de message et rendre un fichier immuable
Lorsque vous devez garantir qu'un fichier ne changera plus une fois intégré dans l'archive, procédez de la manière suivante.
Connectez-vous à l'hôte du système de fichiers en tant qu'utilisateur root:
root@solaris:~#
A l'invite de commande, entrez ssum -a algorithm [-h digest] -F filename, où :
-a algorithm identifie la fonction de hachage cryptographique que le système de fichiers doit utiliser pour valider le fichier par rapport à la synthèse de message fournie.
-h digest identifie la synthèse de message que le système de fichiers doit utiliser pour valider le fichier.
-F demande la validation immédiate et l'immuabilité et définit les attributs de fichier fixity, generate, validated et use. Le système de fichiers calcule et valide immédiatement une synthèse de message. Lorsque le fichier est transféré ou archivé, le système de fichiers calcule et valide une nouvelle synthèse de message.
filename est le chemin et le nom du fichier.
Dans cet exemple, nous fournissons une synthèse SHA256 et demandons au système de fichiers de recalculer la synthèse, de valider sa valeur pour le fichier data20 et de rendre ce fichier immuable. Lorsque nous vérifions les attributs du fichier à l'aide de la commande sls -D -h data10, nous constatons que pour chaque fichier, les attributs fixity, generate, use et validated ont été définis, que l'attribut algorithm a la valeur SHA-256 et que la valeur de la synthèse a été calculée et placée dans l'attribut hash :
root@solaris:~# ssum -h bfaefde932cf...d450892eda63 -a sha256 -F data20 root@solaris:~# sls -D -h data20 data20: mode: -rw-r--r-- links: 1 owner: root group: root length: 14979 admin id: 0 inode: 90264.1 project: user.root(1) access: Jul 16 17:34 modification: Jul 16 17:34 changed: Jul 16 17:34 attributes: Jul 16 17:34 creation: Jul 16 17:34 residence: Jul 16 17:34 checksum: fixity generate use validated algorithm: SHA-256 hash: bfaefde932cf...d450892eda63 root@solaris:~#
Lorsque vous archivez des fichiers auxquels des synthèses de message sont déjà associées, procédez de la manière suivante pour garantir leur immuabilité une fois qu'ils seront intégrés à l'archive.
Connectez-vous à l'hôte du système de fichiers en tant qu'utilisateur root:
root@solaris:~#
A l'invite de commande, entrez ssum -a algorithm [-h digest] -F filename, où :
-a algorithm identifie la fonction de hachage cryptographique qui a été utilisée pour générer la synthèse indiquée dans le paramètre -h digest.
-F définit les attributs de fichier fixity, generate, validated et use. Le système de fichiers calcule et valide immédiatement une synthèse de message. Lorsque le fichier est transféré ou archivé, le système de fichiers calcule et valide une nouvelle synthèse de message.
filename est le chemin et le nom du fichier.
Dans cet exemple, nous demandons au système de fichiers de calculer une synthèse SHA256, de valider sa valeur pour le fichier data200 et de rendre ce fichier immuable. Lorsque nous vérifions les attributs du fichier à l'aide de la commande sls -D -h data10, nous constatons que pour chaque fichier, les attributs de fichier fixity, generate, validated et use ont été définis, que l'attribut algorithm a la valeur SHA-256 et que la valeur de la synthèse a été calculée et placée dans l'attribut hash :
root@solaris:~# ssum -a sha256 -F data200 root@solaris:~# sls -D -h data200 data200: mode: -rw-r--r-- links: 1 owner: root group: root length: 14979 admin id: 0 inode: 90264.1 project: user.root(1) access: Jul 16 17:34 modification: Jul 16 17:34 changed: Jul 16 17:34 attributes: Jul 16 17:34 creation: Jul 16 17:34 residence: Jul 16 17:34 checksum: fixity generate use validated algorithm: SHA-256 hash: efde93cc12cf...d496602e36dd root@solaris:~#
Pour afficher les attributs de synthèse de message et d'immuabilité d'un ou de plusieurs fichiers, utilisez la commande de listage de répertoire d'Oracle HSM, sls. Procédez comme indiqué ci-après.
Connectez-vous à l'hôte du système de fichiers en tant qu'utilisateur root:
root@solaris:~#
A l'invite de commande, entrez sls -D -h filename, où :
-D demande un affichage détaillé des attributs de fichier.
-h inclut la valeur de hachage (synthèse) dans l'affichage.
filename identifie un ou plusieurs fichiers par chemin et nom de fichier.
Dans cet exemple, nous voyons les attributs de synthèse du fichier data02 indiqués dans les champs checksum et hash des résultats affichés :
root@solaris:~# sls -D -h data02 data02: mode: -rw-r--r-- links: 1 owner: root group: root length: 14975 admin id: 0 inode: 90217.1 project: user.root(1) access: Jul 16 16:14 modification: Jul 16 16:14 changed: Jul 16 16:15 attributes: Jul 16 16:14 creation: Jul 16 16:14 residence: Jul 16 16:14 checksum: generate use validated algorithm: SHA-256 hash: f03ce01b3828...f7459503007e root@solaris:~#
L'attribut hash contient la synthèse de message du fichier, à savoir f03ce01b3828...f7459503007e.
L'attribut algorithm indique que la synthèse de message stockée a été générée par la fonction de hachage cryptographique SHA-256.
L'attribut generate indique que le système de fichiers recalcule indépendamment la synthèse de message et la valide par rapport à la valeur stockée chaque fois que le fichier est archivé.
L'attribut use indique que le système de fichiers recalcule indépendamment la synthèse de message et la valide par rapport à la valeur stockée chaque fois que le fichier est transféré.
L'attribut validated indique que la synthèse de message calculée indépendamment correspondait à la valeur stockée dans l'attribut hash lors de la dernière vérification.
L'attribut fixity est affiché si le fichier a été rendu immuable.
Lorsque vous y êtes obligé par la loi ou par des règles d'archivage, vous pouvez créer des répertoires et des fichiers WORM (Write Once Read Many) dans n'importe quel système de fichiers Oracle HSM ayant été configuré pour les prendre en charge. Cette section s'intéresse aux systèmes de fichiers WORM et aux tâches particulières que vous devez accomplir lorsque vous utilisez des fichiers et des répertoires WORM, à savoir :
Pour plus d'informations sur l'activation de la prise en charge de WORM pour un système de fichiers, reportez-vous au document Guide d'installation et de configuration d'Oracle Hierarchical Storage Manager et StorageTek QFS.
Les systèmes de fichiers WORM (Write Once Read Many) protègent les données en permettant aux utilisateurs de rendre les fichiers accessibles en lecture seule pendant la durée d'une période de conservation spécifiée. Les systèmes de fichiers WORM Oracle HSM prennent en charge des périodes de conservation de fichiers par défaut et personnalisables, l'immuabilité des données et des chemins et la transmission du paramètre WORM aux sous-répertoires.
En fonction du mode de configuration de vos systèmes de fichiers, vous pouvez utiliser l'un des deux modes Oracle HSM WORM :
Mode de conformité standard (par défaut)
Mode d'émulation
Dans un système de fichiers monté selon le mode WORM standard, un utilisateur active des répertoires pour WORM et lance la période de conservation en lecture seule pour les fichiers en exécutant la commande chmod 4000 path_name, où path_name représente le chemin et le nom du fichier ou du répertoire. Cette commande définit l'autorisation UNIX setuid (définir l'ID utilisateur lors de l'exécution). La définition de l'autorisation setuid sur un fichier qui présente également l'autorisation execute constitue un risque en matière de sécurité ; c'est pourquoi en mode WORM standard, seuls les fichiers non exécutables peuvent être rendus accessibles en lecture seule.
Dans un système de fichiers monté selon le mode d'émulation WORM, un utilisateur active des répertoires pour WORM et lance la période de conservation en lecture seule pour les fichiers en exécutant la commande chmod 555 path_name, où path_name représente le chemin et le nom d'un fichier ou d'un répertoire accessible en écriture. Comme le mode d'émulation ne nécessite pas l'autorisation setuid, les fichiers exécutables peuvent être rendus accessibles en lecture seule et soumis à des périodes de conservation.
Les modes standard et d'émulation disposent d'une implémentation WORM stricte et d'une implémentation lite moins restrictive. Les implémentations stricte et lite ne permettent pas de modifier les données ou les chemins une fois que la conservation a été déclenchée pour un fichier ou un répertoire. Toutes les deux définissent une période de conservation par défaut de 43200 minutes (30 jours). Toutefois, l'implémentation lite assouplit certaines restrictions pour les utilisateurs root.
Les implémentations strictes ne permettent à personne de réduire la période de conservation indiquée ni de supprimer des fichiers ou des répertoires avant la fin de la période de conservation. Elles ne permettent également à personne d'utiliser la commande sammkfs pour supprimer les volumes contenant des fichiers et répertoires en cours de conservation. Les implémentations strictes sont donc bien adaptées aux exigences les plus sévères en matière de conformité juridique et réglementaire et de préservation.
Les implémentations lite permettent aux utilisateurs root de réduire les périodes de conservation, de supprimer des fichiers et des répertoires et de supprimer des volumes à l'aide de la commande sammkfs. Cela assure un niveau élevé de protection contre les pertes de données anodines et permet une administration plus souple des systèmes de fichiers et des ressources de stockage. En revanche, les systèmes de fichiers qui laissent aux superutilisateurs un tel degré de contrôle risquent de ne pas répondre à certaines exigences de conformité juridique et réglementaire.
Vous pouvez créer des liens symboliques ou physiques vers les fichiers WORM. Vous pouvez uniquement créer des liens physiques avec des fichiers se trouvant dans un répertoire WORM. Après sa création, un lien physique a les mêmes caractéristiques WORM que le fichier d'origine. Vous pouvez également établir des liens symboliques, mais ceux-ci ne sont pas en mesure de tirer parti des fonctions WORM. Vous pouvez créer des liens symboliques vers des fichiers WORM dans n'importe quel répertoire d'un système de fichiers Oracle HSM.
Pour obtenir des informations complètes sur la création et la configuration de systèmes de fichiers WORM, reportez-vous au document Guide d'installation et de configuration d'Oracle Hierarchical Storage Manager et StorageTek QFS, disponible dans la Bibliothèque de documentation client.
Lorsque vous activez WORM pour un répertoire, vous y ajoutez la prise en charge de fichiers WORM mais ne modifiez pas pour autant les caractéristiques de ce répertoire. Les utilisateurs peuvent continuer de créer et modifier des fichiers dans un répertoire activé pour WORM. Par ailleurs, il est possible de supprimer un répertoire activé pour WORM s'il ne contient pas de fichiers WORM. Pour activer WORM sur un répertoire, procédez de la manière suivante :
Connectez-vous au serveur de système de fichiers.
user@solaris:~#
Vérifiez si le répertoire a déjà été activé pour WORM. Exécutez la commande sls -Dd directory, où directory est le chemin et le nom du répertoire. Recherchez l'attribut worm-capable dans la sortie de la commande.
En général, les répertoires sont activés pour WORM. En effet, lorsqu'un utilisateur active WORM sur un répertoire, tous les répertoires enfants (existants et futurs) héritent de la compatibilité WORM (pour plus d'informations sur la commande, reportez-vous à la page de manuel sls). Dans le premier exemple, notre répertoire cible /hsm/hsmfs1/records est déjà activé pour WORM :
user@solaris:~# sls -Dd /hsm/hsmfs1/records/2013/ /hsm/hsmfs1/records/2013: mode: drwxr-xr-x links: 2 owner: root group: root length: 4096 admin id: 0 inode: 1048.1 project: user.root(1) access: Mar 3 12:15 modification: Mar 3 12:15 changed: Mar 3 12:15 attributes: Mar 3 12:15 creation: Mar 3 12:15 residence: Mar 3 12:15 worm-capable retention-period: 0y, 30d, 0h, 0m
Dans le second exemple, en revanche, le répertoire cible /hsm/hsmfs1/documents n'est pas activé pour WORM :
user@solaris:~# sls -Dd /hsm/hsmfs1/documents /hsm/hsmfs1/documents mode: drwxr-xr-x links: 2 owner: root group: root length: 4096 admin id: 0 inode: 1049.1 project: user.root(1) access: Mar 3 12:28 modification: Mar 3 12:28 changed: Mar 3 12:28 attributes: Mar 3 12:28 creation: Mar 3 12:28 residence: Mar 3 12:28
Si le répertoire n'est pas compatible avec WORM et que le système de fichiers a été monté avec l'option worm_capable ou worm_lite, activez la prise en charge de WORM à l'aide de la commande Solaris chmod 4000 directory-name, où directory-name représente le chemin et le nom du répertoire devant contenir les fichiers WORM.
La commande chmod 4000 définit l'attribut setuid (définir l'ID utilisateur à l'exécution) sur le répertoire indiqué et active la prise en charge de WORM en mode standard. Dans cet exemple, nous rendons le répertoire /hsm/hsmfs1/documents compatible avec WORM et vérifions le résultat à l'aide de la commande sls -Dd. L'opération réussit et le répertoire est activé pour WORM :
user@solaris:~# chmod 4000 /hsm/hsmfs1/documents user@solaris:~# sls -Dd /hsm/hsmfs1/documents /hsm/hsmfs1/documents mode: drwxr-xr-x links: 2 owner: root group: root length: 4096 admin id: 0 inode: 1049.1 project: user.root(1) access: Mar 3 12:28 modification: Mar 3 12:28 changed: Mar 3 12:28 attributes: Mar 3 12:28 creation: Mar 3 12:28 residence: Mar 3 12:28 worm-capable retention-period: 0y, 30d, 0h, 0m
Si le répertoire n'est pas compatible avec WORM et que le système de fichiers a été monté avec l'option worm_emul ou emul_lite, activez la prise en charge de WORM à l'aide de la commande Solaris chmod 555 directory-name, où directory-name représente le chemin et le nom du répertoire devant contenir les fichiers WORM.
La commande chmod 555 supprime les autorisations d'écriture sur le répertoire et active la prise en charge du mode d'émulation WORM. Dans cet exemple, nous rendons le répertoire /hsm/hsmfs1/documents compatible avec WORM et vérifions le résultat à l'aide de la commande sls -Dd. L'opération réussit et le répertoire est activé pour WORM :
user@solaris:~# chmod 555 /hsm/hsmfs1/documents user@solaris:~# sls -Dd /hsm/hsmfs1/documents /hsm/hsmfs1/documents mode: drwxr-xr-x links: 2 owner: root group: root length: 4096 admin id: 0 inode: 1049.1 project: user.root(1) access: Mar 3 12:28 modification: Mar 3 12:28 changed: Mar 3 12:28 attributes: Mar 3 12:28 creation: Mar 3 12:28 residence: Mar 3 12:28 worm-capable retention-period: 0y, 30d, 0h, 0m
Lorsque vous activez la protection WORM pour un fichier stocké dans un répertoire compatible avec WORM, le système de fichiers n'autorise plus la modification des données de ce fichier ni de leur chemin jusqu'à l'expiration de la période de conservation. Vous devez donc faire preuve de prudence. Pour activer la protection WORM, procédez de la manière suivante :
Connectez-vous au serveur de système de fichiers.
user@solaris:~#
Si vous devez conserver le fichier pendant une durée différente de la valeur par défaut définie pour le système de fichiers, indiquez la durée de conservation souhaitée en modifiant le temps d'accès au fichier. Utilisez la commande Solaris touch -a -texpiration-date path-name, où :
expiration-date est une chaîne numérique composée de quatre chiffres pour l'année, deux chiffres pour le mois, deux chiffres pour le jour du mois, deux chiffres pour l'heure, deux chiffres pour les minutes et éventuellement deux chiffres pour les secondes.
path-name représente le chemin et le nom du fichier.
Remarque : les utilitaires UNIX Oracle Solaris tels que touch ne peuvent pas étendre la période de conservation au-delà du 18/01/2038 à 22h14. Ces utilitaires utilisent des nombres 32–bits signés pour représenter le temps en secondes à partir du 01/01/1970. Par conséquent, vous devez utiliser la période de conservation par défaut si vous devez conserver des fichiers après cette échéance.
Dans cet exemple, nous définissons une période de conservation du fichier qui expire quatre ans plus tard, le 4 octobre 2019 à 11h59 :
user@solaris:~# touch -a -t201910141159 /hsm/hsmfs1/plans/master.odt
Si le système de fichiers a été monté avec l'option worm_capable ou worm_lite, activez la protection WORM à l'aide de la commande Solaris chmod 4000 path-name, où path-name représente le chemin et le nom du fichier.
La commande chmod 4000 définit l'attribut setuid (définir l'ID utilisateur à l'exécution) sur le fichier indiqué. Il n'est pas sûr de définir cet attribut pour un fichier exécutable. Par conséquent, si le système de fichiers a été monté avec l'option worm_capable ou worm_lite, vous ne pouvez pas définir la protection WORM sur les fichiers présentant l'autorisation UNIX execute.
Dans cet exemple, nous activons la protection WORM pour le fichier master.odt. Nous vérifions le résultats à l'aide de la commande sls -D et remarquons que l'attribut retention a désormais le statut active, avec une période de conservation retention-period définie sur quatre ans :
user@solaris:~# chmod 4000 /hsm/hsmfs1/plans/master.odt user@solaris:~# sls -Dd /hsm/hsmfs1/plans/master.odt /hsm/hsmfs1/plans/master.odt: mode: -r-xr-xr-x links: 1 owner: root group: root length: 104 admin id: 0 inode: 1051.1 project: user.root(1) access: Mar 4 2018 modification: Mar 3 13:14 changed: Mar 3 13:16 retention-end: Apr 2 14:16 2014 creation: Mar 3 13:16 residence: Mar 3 13:16 retention: active retention-period: 4y, 0d, 0h, 0m
Si le système de fichiers a été monté avec l'option worm_emul ou emul_lite, activez la protection WORM à l'aide de la commande Solaris chmod 555 path-name, où path-name représente le chemin et le nom du fichier.
La commande chmod 555 supprime les autorisations d'écriture sur le répertoire. La protection WORM peut donc être appliquée à des fichiers exécutables si nécessaire. Dans cet exemple, nous activons la conservation WORM pour le fichier master-plan.odt. Nous vérifions le résultats à l'aide de la commande sls -D et remarquons que l'attribut retention a désormais le statut active, avec une période de conservation retention-period définie sur quatre ans :
user@solaris:~# chmod 555 /hsm/hsmfs1/plans/master.odt user@solaris:~# sls -Dd /hsm/hsmfs1/plans/master.odt /hsm/hsmfs1/plans/master.odt: mode: -r-xr-xr-x links: 1 owner: root group: root length: 104 admin id: 0 inode: 1051.1 project: user.root(1) access: Mar 4 2018 modification: Mar 3 13:14 changed: Mar 3 13:16 retention-end: Apr 2 14:16 2014 creation: Mar 3 13:16 residence: Mar 3 13:16 retention: active retention-period: 4y, 0d, 0h, 0m
Pour rechercher et établir la liste des fichiers WORM qui répondent aux critères de recherche indiqués, utilisez la commande sfind. La procédure est la suivante :
Connectez-vous au serveur de système de fichiers.
user@solaris:~#
Pour dresser la liste des fichiers bénéficiant de la protection WORM et conservés de façon active, utilisez la commande sfind starting-directory -ractive, où starting-directory est le chemin et le nom du répertoire où vous souhaitez commencer l'établissement de la liste.
user@solaris:~# sfind /hsm/hsmfs1/ -ractive /hsm/hsmfs1/documents/2013/master-plan.odt /hsm/hsmfs1/documents/2013/schedule.ods /samma1/records/2013/progress/report01.odt /samma1/records/2013/progress/report02.odt /samma1/records/2013/progress/report03.odt ... user@solaris:~#
Pour établir la liste des fichiers bénéficiant d'une protection WORM pour lesquels la période de conservation a expiré, utilisez la commande sfind starting-directory -rover, où starting-directory est le chemin et le nom du répertoire où vous souhaitez commencer l'établissement de la liste.
user@solaris:~# sfind /hsm/hsmfs1/ -rover /samma1/documents/2007/master-plan.odt /samma1/documents/2007/schedule.ods user@solaris:~#
Pour établir la liste des fichiers bénéficiant de la protection WORM pour lesquels la période de conservation va expirer à une date et une heure précises, utilisez la commande sfind starting-directory -rafter expiration-date, où :
starting-directory est le chemin et le nom du répertoire où vous souhaitez lancer l'établissement de la liste.
expiration-date est une chaîne numérique composée de quatre chiffres pour l'année, deux chiffres pour le mois, deux chiffres pour le jour du mois, deux chiffres pour l'heure, deux chiffres pour les minutes et éventuellement deux chiffres pour les secondes.
Dans cet exemple, nous répertorions tous les fichiers pour lesquels la période de conservation expire après le 1er janvier 2015 à 00h01 :
user@solaris:~# sfind /hsm/hsmfs1/ -rafter 201501010001 /hsm/hsmfs1/documents/2013/master-plan.odt user@solaris:~#
Pour établir la liste des fichiers bénéficiant d'une protection WORM qui doivent demeurer dans le système de fichiers pendant une période minimale indiquée, utilisez la commande sfind starting-directory -rremain time-remaining, où :
starting-directory est l'emplacement dans l'arborescence de l'annuaire où démarre la recherche.
time-remaining est une chaîne d'entiers positifs associée aux unités de temps suivantes : y pour années, d pour jours, h pour heures, m pour minutes.
Dans cet exemple, nous trouvons tous les fichiers sous le répertoire /hsm/hsmfs1/ qui seront conservés pendant au moins trois années supplémentaires :
user@solaris:~# sfind /hsm/hsmfs1/ -rremain 3y /hsm/hsmfs1/documents/2013/master-plan.odt user@solaris:~#
Pour établir la liste des fichiers bénéficiant d'une protection WORM qui doivent demeurer dans le système de fichiers plus longtemps qu'une durée donnée, utilisez la commande sfind starting-directory -rlonger time, où :
starting-directory est l'emplacement dans l'arborescence de l'annuaire où démarre la recherche.
time-remaining est une chaîne d'entiers positifs associée aux unités de temps suivantes : y pour années, d pour jours, h pour heures, m pour minutes.
Dans cet exemple, nous trouvons tous les fichiers sous le répertoire /hsm/hsmfs1/ qui seront conservés plus de trois ans et 90 jours :
user@solaris:~# sfind /hsm/hsmfs1/ -rremain 3y90d /hsm/hsmfs1/documents/2013/master-plan.odt user@solaris:~#
Pour établir la liste des fichiers bénéficiant d'une protection WORM qui doivent demeurer dans le système de fichiers de manière permanente, utilisez la commande sfind starting-directory -rpermanent.
Dans cet exemple, nous observons qu'aucun fichier sous le répertoire /hsm/hsmfs1/ n'est conservé de manière permanente :
user@solaris:~# sfind /hsm/hsmfs1/ -rpermanent user@solaris:~#