3 Fonctions de sécurité

Pour éviter des menaces de sécurité potentielles, les clients exécutant DIVAnet doivent faire attention à l'authentification et à l'autorisation du système.

Ces menaces de sécurité peuvent être réduites grâce à une configuration adéquate et à la vérification de la liste des contrôles post-installation fournie dans l'Annexe A.

Modèle de sécurité

Les fonctionnalités de sécurité critiques suivantes protègent contre les menaces de sécurité :

  • Authentification : garantit que seules les personnes autorisées peuvent accéder au système et aux données.

  • Autorisation : fournit un contrôle d'accès aux privilèges et aux données du système. Cette fonctionnalité repose sur l'authentification afin de garantir que chaque individu dispose uniquement de l'accès dont il a besoin.

Authentification

Les services DIVAnet peuvent utiliser plusieurs méthodes pour assurer l'authentification :

  • Certificats SSL/TLS : DIVAnet consulte un truststore de certificats lorsqu'il crée une connexion sortante à un service DIVAnet distant. Cela permet de garantir que DIVAnet est connecté à des services DIVAnet authentiques. Pour créer une connexion sécurisée à partir du service ClientAdapter de DIVAnet vers une instance DIVArchive, vous devez vous connecter via le service ManagerAdapter en utilisant un type de connexion ConnectionType identifié comme WebServices.

  • Règles d'accès : Elles constituent techniquement une forme de contrôle d'accès et peuvent filtrer les connexions entrantes en fonction de l'adresse IP entrante. Cette fonctionnalité est nécessaire pour garantir que seuls les systèmes approuvés ont un accès approprié aux services DIVAnet.

AVERTISSEMENT :

Les services DIVAnet utilisent des mots de passe de base de données dans leur configuration. Il convient de modifier ces mots de passe immédiatement après l'installation, puis au minimum tous les 180 jours par la suite. Une fois que vous avez changé les mots de passe, vous devez les stocker dans un emplacement sécurisé, hors ligne, où ils peuvent être mis à la disposition du support technique Oracle si nécessaire.

Contrôle d'accès

Vous pouvez créer des règles d'accès pour limiter les opérations que certains utilisateurs ou systèmes peuvent effectuer dans le système d'archivage distribué. Les règles d'accès peuvent être exécutées comme suit :

  • ClientAdapter/Mode MultiDiva : limite les types de demandes DIVAnet pouvant être exécutées.

  • ManagerAdapter : limite les types de demandes DIVArchive pouvant être exécutés pour satisfaire une demande DIVAnet (potentiellement demandée par un système distant).

Les règles d'accès peuvent affecter les demandes lancées à partir de l'interface utilisateur DIVAnetUI ou d'une connexion de socket d'API (potentiellement lancée par une solution MAM ou un système d'automatisation).

Les règles d'accès peuvent être exécutées sur une demande DIVAnet au niveau de DIVAnet ou de DIVArchive. Au niveau de DIVAnet, le service ClientAdapter traite la demande où elle est reçue. Au niveau de DIVArchive, un service ManagerAdapter distant traite les demandes DIVArchive émises pour satisfaire la demande DIVAnet.

Oracle recommande de créer l'ensemble de règles le plus restrictif possible répondant aux exigences de l'application. Par exemple, si seuls les administrateurs ont besoin d'effectuer des suppressions globales, assurez-vous que les autres utilisateurs n'ont pas accès à cette fonctionnalité. Si un groupe d'utilisateurs système a seulement besoin d'accéder à une liste déterminée de sources et destinations, assurez-vous que ces utilisateurs ne peuvent émettre des demandes que pour ces sources et destinations spécifiques.

Tenez compte également des sites utilisés pour satisfaire aux demandes. Par exemple, si les utilisateurs sur le site local n'ont aucune raison d'effectuer des copies alors que ni le site source ni le site cible n'est le site local (cela est possible avec DIVAnet), configurez ces règles dans la configuration du service ClientAdapter.

Enfin, tenez compte des constructions spécifiques dans les demandes que vous voulez exclure systématiquement. Par exemple, si vous n'avez pas besoin d'adresser les objets avec seulement le nom d'objet (sans la catégorie), excluez toutes les demandes dont les catégories sont vides.

De plus, chaque WorkflowProfile de ClientAdapter contient la liste des messages valides pouvant être traités par les demande affectées à ce WorkflowProfile. En mode MultiDiva, cela permet d'exclure du traitement des messages spécifiques (notamment les messages d'information).

Oracle recommande de commencer par les règles par défaut définies dans le fichier AccessRules.xml.ini, même si vous ne définissez pas vos propres règles d'accès. Pour plus d'informations sur les fonctionnalités de contrôle d'accès de DIVAnet, reportez-vous au Guide d'installation, de configuration et d'utilisation d'Oracle DIVAnet à l'adresse suivante :

https://docs.oracle.com/en/storage/#csm

Configuration des certificats SSL/TLS

DIVAnet stocke les données des certificats à deux endroits : un fichier de clés privées utilisé pour les services Web hébergés sur le système local et un fichier de clés publiques, utilisé pour vérifier les services Web qui sont appelés à distance. Vous pouvez utiliser l'utilitaire Java Keytool pour changer le mot de passe du fichier de clés et pour ajouter ou supprimer des certificats.

Reportez-vous au site suivant pour plus d'informations sur la création des fichiers de clés :

http://docs.oracle.com/javase/8/docs/technotes/guides/security/jsse/JSSERefGuide.html#CreateKeystore

Seules les connexions aux services Web DIVAnet utilisent des certificats SSL/TLS. Dans cette version, la connexion à DIVArchive ou DIVAnet au moyen d'une connexion de socket d'API DIVArchive n'utilisera pas SSL/TLS.

Fichier de clés privées

Les données des certificats de clés privées DIVAnet sont stockées dans :

$DIVANET_HOME/Program/divanet/lib/diva129.jks

Un seul certificat exactement doit apparaître dans ce fichier de clés. Ce certificat est utilisé pour les services Web hébergés par les services exécutés à partir de ce répertoire $DIVANET_HOME. Il est recommandé de remplacer le certificat fourni par un nouveau certificat et d'utiliser un certificat différent pour chaque site DIVAnet du réseau.

Vous devez changer le mot de passe de ce fichier de clés. Stockez les informations de mot de passe dans un nouveau fichier intitulé $DIVANET_HOME/Program/divanet/lib/diva129.properties et rendez ce fichier lisible par les services DIVAnet (utilisateur divanetsvc dans Linux), mais non lisible par les utilisateurs occasionnels du système (tel que l'utilisateur diva dans Linux).. Utilisez le format suivant pour ce fichier :

keystorePassword=newpassword

Fichier de clés publiques

Parfois appelé truststore. Ces données sont situées dans :

$DIVANET_HOME/Java/lib/security/cacerts2

Ces données de certificat sont utilisées dans les appels de service Web sortants (notamment DIVAnetUI). Vous pouvez charger plusieurs clés publiques dans ce fichier de clés.

Si vous avez ajouté un nouveau certificat autosigné dans le fichier de clés privées DIVAnet, exportez ce certificat au moyen de l'utilitaire keytool. Toutes les applications (services DIVAnet, interface DIVAnetUI, etc.) qui appellent WebServices sur ce site doivent ensuite ajouter le certificat exporté à leur propre fichier de clés publiques.