Tout d'abord l'écriture des données est réalisée via le réseau IP de l'entreprise par l’un des protocoles activés (CIFS, NFS, HTTPs, …). Dès réception complète de la donnée, sa prise en compte par HCP débute par le calcul d’une empreinte avec un des algorithmes du HCP MD5, SHA, etc. L'empreinte est enregistrée dans un premier fichier dédié nommé core-metadata.xml et dans un second fichier nommé hash.txt. Les deux fichiers, non modifiables, sont présents dans l'arborescence Metadata et accessibles, depuis le réseau IP, via l’un des protocoles activés (CIFS, NFS, HTTPs, …). Une fois déposé le nom du fichier et son contenu ne peuvent être changés, même si la date de rétention est nulle ou arrivée au terme de sa conservation. Tout au long de la conservation du fichier, un processus spécifique (nommé Scavenging) interne à la plate-forme HCP effectue des vérifications sur son intégrité. Une vérification est aussi réalisée lors d'un accès en lecture au fichier.
Par exemple, pour la partie accès CIFS, HCP utilise des codes retours associés à ce protocole, comme le NT_STATUS_ACCESS_DENIED. Ce code retour est renvoyé pour refuser les opérations suivantes : renommer un objet ; renommer ou détruire un répertoire qui contient au moins un objet ; écraser un objet ; modifier le contenu d'un objet ; détruire un objet sous rétention ; ajouter un fichier dans la partie métadonnées à l'exception du fichier custom-metadata.xml ; détruire un fichier ou un répertoire Métadonnée et créer un lien. Ces interdictions sont une liste des actions qui permettent de garantir qu’il n’y a aucune possibilité de substitution des données.
Avec l’utilisation du mode Réplica (Data Protection Level), chaque fichier (archive) déposé est systématiquement dupliqué en interne vers une zone de stockage différente et gérée par un autre serveur. Ainsi le dépôt source et sa copie sont situés sur des Groupes RAID-6 physiques différents, dont l'accès est géré par des serveurs (contrôleurs) différents. En cas d'altération du fichier, HCP reconstruit automatiquement le fichier, et les métadonnées, à partir de sa copie et ajoute une information dans les Logs (début, arrêt avant la fin, violation, fin et succès du traitement).
Dés son enregistrement la donnée ne peut être modifiée et ne peut être substituée, même par le propriétaire. Toute opération d'ouverture du fichier en mode écriture est strictement interdite, même si le fichier est au delà de sa période de rétention. Le système de fichiers POSIX de stockage des fichiers est contrôlé directement par HCP. Aucun mécanisme ne permet d'interférer dans la modification ou le remplacement d'un fichier pendant la période de rétention. Après la période de rétention et en fonction des autorisations d'accès, la seule opération autorisée est la suppression définitive du fichier.
En cas de suppression après la rétention, puis copie d'un nouveau fichier dans un objectif de substitution, il sera possible de détecter l'opération, car HCP enregistre la date de dépôt, donc la date du fichier de substitution éventuelle. Cette date de dépôt est enregistrée dans un premier fichier nommée core-metadata.xml et dans un second fichier nommé created.txt. Les deux fichiers sont non modifiables, présents dans l'arborescence Metadata et accessibles, depuis le réseau IP, via l’un des protocoles activés (CIFS, NFS, HTTPs, …). En cas de fichier dit non réparable, c'est-à-dire que le fichier source est détecté comme altéré et que sa restauration par sa copie interne (Replica) échoue, une notification d'alerte est enregistrée (SNMP et Syslog). L'interface graphique d'administration propose aussi une vue spécifique sur ces fichiers corrompus.
Le journal des évènements du système HCP (System Log Events) comprend des informations liées à l'activité de la plate-forme : arrêt, démarrage, suppression de compte, sauvegarde, mot de passe invalide, service spécifique stoppé, lien réseau, serveur de temps inaccessible, etc.
L'accès à ces Logs s'effectue principalement via 3 modes : l'interface d'administration avec les droits Monitor; le protocole SNMP et le protocole Syslog. Syslog est le protocole le plus couramment utilisé. Il s'agit d'un service de journaux d'événements d'un système informatique, mais donne aussi son nom au format d'échange. Ce protocole se compose d'une partie Client et d'une partie Serveur. HCP se comporte comme un client en émettant les informations sur le réseau via le port UDP 514. La partie serveur doit collecter les informations, pour centraliser les journaux d'événements.
Un événement HCP est composé d'un identifiant unique, le numéro de segment du message (un événement Syslog ne peut excéder 1024 caractères, celui-ci peut donc être découpé en plusieurs segments), l'identifiant de l'événement, la date, la sévérité, l'identification du serveur HCP, le volume (stockage) concerné, le nom de l'utilisateur éventuel lié à l'événement, une courte description de l'événement (uniquement pour SNMP ) et le message complet.
En plus des événements systèmes envoyés par les protocoles SNMP et Syslog, HCP maintiens des Logs internes. Il s'agit d'enregistrements sur l'activité des composants HCP. Ces Logs internes sont uniquement utiles à diagnostiquer un problème interne par le support Hitachi. Ces Logs internes sont conservés sur une période de 35 jours. Lors d'une récupération par un téléchargement depuis l'interface d'administration, le fichier récupéré est encrypté et ne peut être lu que par le support Hitachi.
La destruction d'un fichier ne peut être réalisée qu'au terme de la rétention. L'ordre de suppression n'est pas réalisé par HCP, mais doit être donnée par l'application Métier (ou Collecteur). Elle se réalise via l’un des protocoles activés (CIFS, NFS, HTTPs, …), comme pour un fichier standard. L'ordre de suppression provoque dans la solution Hitachi Content Platform la suppression du fichier cible, de sa copie interne (Réplica : Data Protection Level) et des métadonnées associées. Cette suppression est accompagnée d'une opération dite de Shredding (suppression sécurisée). C'est-à-dire la mise en œuvre d'une opération de suppression effective des données sur le disque et non uniquement d'une suppression des descripteurs (inodes ou pointeurs). Ce mécanisme normé assure que le contenu du fichier ne pourra être lu même par une lecture physique du disque dur.
Le traitement d'une opération de Shredding peut faire l'objet d'un enregistrement d'évènement pour être collecté via le protocole Syslog.
Le support natif du protocole HTTP embarque aussi l’intégration des accès par WebDAV, REST ou cURL. Ainsi, en plus des protocoles CIFS et NFS pour un accès direct en mode système de fichiers, il est très aisé d’utiliser les modes d’accès Web pour dialoguer avec la solution HCP, afin d’assurer l’écriture (Upload) et la lecture (Download) de tout type de document.
En exemple et pour illustrer la simplification et la facilité de développement sur HCP, la librairie cURL est disponible dans le domaine public en ligne de commande sur un très grand nombre de systèmes d’exploitation, mais aussi via client REST et le langage PHP.
Via HTTP, le mode Web est privilégié, car il autorise des accès non dépendant d’un réseau local et permet des niveaux de performance en accord avec l’architecture Cloud réparti du HCP, par le traitement parallèle des flux entrants et sortants, car tous les serveurs HCP sont disponibles et travaillent ensemble à la répartition des charges et du stockage des documents. Plus le nombre de serveurs HCP est important plus le nombre de traitement parallèle est possible, tout en accédant à un seul espace de stockage consolidé.
SNMP et Syslog contribuent aussi à une intégration avancée et au développement d’application au-dessus de la solution HCP. Le premier au niveau administration de la plate-forme. Le second à la collecte des journaux d’activité et la traçabilité.
L’archivage des e-mails peut-être réalisé à travers des outils de délestage de messagerie qui collecte les e-mails et les pièces jointes et effectuent un enregistrement sur le stockage HCP.
Dans le cadre d’un archivage avec une orientation dite Compliant ou Valeur Probante, c’est-à-dire de conservation probante sur un support adapté (WORM logique), il est permis d’envoyer directement les e-mails via le protocole SMTP qui est nativement supporté par HCP. Ainsi, un administrateur de messagerie peut définir des règles de transfert vers HCP directement à partir de son application de messagerie. Par exemple, Microsoft Exchange 2010 propose tout un service applicatif, au travers de la journalisation des e-mails et leurs pièces jointes sont envoyés sur HCP, pour y être stockés dans une arborescence fichiers et être classifiés automatiquement par date. Le moteur d’indexation HCP peut être utilisé, afin de retrouver les e-mails par propriétaire, destinataire ou contenu, même au sein des documents en attachement.
Le marché du traitement sécurisé des Journaux d’Évènements (Syslog, SNMP, etc.)est une cible pour la solution Hitachi Content Platform. Les journaux d’évènements sont une source de détection et d’analyse d’incidents, de traçabilité et surtout de sécurité, pour comprendre et interpréter une activité afin d’apporter les corrections préventives sur les causes identifiées. Il est nécessaire de conserver ces informations et d'en assurer l'intégrité. Au travers du protocole SMTP disponible de base dans la solution HCP, il est aisé d'envoyer des messages électroniques avec des documents attachés issus de traces (Logs) d'activités de divers systèmes applicatifs et équipements informatiques. L'utilisation du moteur d'indexation interne et des interfaces de recherche de la solution HCP facilite les exigences sur les audits, les métriques et la réalisation de tableaux de bord.
Chaque entreprise est confrontée à la gestion de ce type d’information et, pour une part, à leur conservation réglementée. En dehors du service informatique de base qui consiste à suivre et interpréter la corrélation d’incidents, une bonne gestion et conservation des Évènements permet aussi de répondre à des contraintes de sécurité et de responsabilité avec plus ou moins d’inhérence suivant les secteurs.
Ce marché sera d’autant plus important que la réglementation évolue avec la notion de traçabilité des activités, telle que la conformité à la norme ISO 27001 qui prend de l’ampleur et qui intéresse fortement les RSSI. L’objet de cette norme est de définir les mesures nécessaires à la sécurité des biens sensibles de l’entreprise liés à son système d’information. HCP n’est pas directement « certifié » ISO 27001, mais est un outil informatique s’intégrant et facilitant la mise en œuvre d’une stratégie liée à cette norme pour le Système de Management de la Sécurité de l'Information (SMSI).