5.10. Gestion des profils de sécurité

La solution logicielle VITAM permet de gérer des profils de sécurité.

Le profil se base sur un contexte, lui-même basé sur une/des certificat(s).

Le processus d’installation met en place le profil de sécurité d’administration, qu’il est fortement recommandé de laisser « tel quel », car ce dernier est utilisé pour des actes d’exploitation.

Il n’existe actuellement pas de point d’API permettant de mettre à jour des profils de sécurité directement dans leur globalité, il sera donc nécessaire de les supprimer puis de l’ajouter à nouveau selon la procédure ci-dessous.

5.10.1. Hiérarchie : profils de sécurité, contextes et certificats

Afin d’avoir une vue ensembliste sur la relation entre les profils de sécurité, les contextes et les certificats déjà importés dans VITAM, il est possible d’avoir une liste complète des données de ces collections, en tenant compte de leur interdépendance.

Cette action est faite en lançant le playbook comme suit :

ansible-playbook ansible-vitam-exploitation/listing_securityProfiles_contexts_certificates_hierarchy.yml -i environments/hosts.<environnement> –ask-vault-pass

Note

Les certificats personnels ne sont pas pris en compte dans ce listage, vu qu’ils dépendent plutôt du client connecté et non pas du contexte.

5.10.2. Ajout/Suppression de profils de sécurité

Avertissement

Cette version est encore en cours de mise en place et est susceptible d’évoluer.

5.10.2.1. Configuration

Un playbook d’exploitation permet de rajouter des profils de sécurité.

Sur la machine de déploiement, il est nécessaire de configurer le fichier deployment/environments/group_vars/all/postinstall_param.yml, dans la section vitam_additional_securityprofiles.

Exemple :

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
---

vitam_additional_securityprofiles:
  - name: applicative01
    identifier: spidentifier01 # manadatory, cannot be naither null nor blank
    hasFullAccess: false # true/false
    permissions: "null" # possible keypairs are stored in "modèle de données"  ; for example : "contexts:read"
    contexts:
      - name: contextappli01
        identifier: myContextIdentifier # please leave blank if associated tenants are "master" (if over release 9,related to existence of CONTEXT in vitam_tenants_usage_external directive for tenant)
        status: ACTIVE # ACTIVE or INACTIVE
        enable_control: true # can be true or false , must be true if fine permissions tuning (see above) ; if false, no permissions
        permissions: "[ { \"tenant\": 2, \"AccessContracts\": [], \"IngestContracts\": [] }]" # you can specify different permissions for all tenants that have to be associated to "[{perms1},{perms2}, ...]" where permsX is  something like { \"tenant\": 2, \"AccessContracts\": [], \"IngestContracts\": [] }
        certificates: ['cert1.crt'] # list of public certificates files stored in {{inventory_dir}}/certs/client-external/clients/

Note

les certificats devraient être de type external/${fichier crt}.

5.10.2.2. Ajout des fichiers crt

Placer les certificats précédemment renseignés (fichiers crt) dans {{inventory_dir}}/certs/client-external/clients/external/.

5.10.2.3. Lancement du playbook

  • L’ajout de tous les profils de sécurité renseignés dans postinstall_param.yml se fait en lançant le playbook comme suit :

    ansible-playbook ansible-vitam-exploitation/add_contexts.yml -i environments/hosts.<environnement> –ask-vault-pass

Prudence

Ce playbook ne sait gérer que le cas d’ajout de profils/contextes/… . Il convient de s’assurer au préalable que les champs name et identifier à ajouter n’existent pas déjà dans la solution logicielle VITAM.

  • L’ajout d’un seul profil de sécurité issu du fichier postinstall_param.yml se fait en lançant le playbook comme suit :

    ansible-playbook ansible-vitam-exploitation/add_contexts.yml -i environments/hosts.<environnement> -e security_profile_id= »<security_profile_id> » –ask-vault-pass

  • La suppression de tous les profils de sécurité se fait en lançant le playbook comme suit :

    ansible-playbook ansible-vitam-exploitation/remove_contexts.yml -i environments/hosts.<environnement> –ask-vault-pass

Prudence

Ce playbook supprime l’ensemble des profils/contextes définis dans le fichier environments/group_vars/all/postinstall_param.yml.

  • La suppression d’un seul profil de sécurité se fait en lançant le playbook comme suit :

    ansible-playbook ansible-vitam-exploitation/remove_contexts.yml -i environments/hosts.<environnement> -e security_profile_id= »<security_profile_id> » –ask-vault-pass

Prudence

Les opérations sur le contexte de sécurité admin-context sont interdites car réservé à Vitam.

  • L’ajout d’un certificat pour un profil de sécurité existant se fait de la manière suivante :

    ansible-playbook ansible-vitam-exploitation/update_context.yml -i environments/hosts.<environnement> -e security_profile_id= »<security_profile_id> » –ask-vault-pass

Prudence

Le profil de sécurité doit exister et il ne faut pas que plusieurs certificats identiques soient insérés !

5.10.2.4. Reconfiguration de VITAM

À l’issue de la bonne exécution du playbook, il faut relancer un déploiement partiel de VITAM pour les groupes ansible [hosts_ingest_external] et [hosts_access_external]

5.10.2.4.1. Si utilisation de la PKI de tests

La procédure décrite ci-dessous est à appliquer dans le cas où la PKI de tests a été employée.

Ajouter les informations relatives au(x) certificat(s) supplémentaire(s) via la commande

ansible-vault edit environments/certs/vault-certs.yml --ask-vault-pass

Ajouter un couple clef/valeur pour chaque certificat supplémentaire selon le modèle suivant

client_client-external_<nom complet du fichier crt avec extension>_key: <la valeur du mot de passe>

Exemple:

client_client-external_appliexterne.crt_key: Motd3P@sse!

Note

appliexterne ne doit pas contenir de caractère « -« 

Avertissement

Si le certificat à ajouter a été généré avec une CA non-connue de VITAM, il faut ajouter au bon endroit la clé publique (se référer au DIN pour plus d’informations).

Prudence

Un fichier crt ne doit contenir qu’une clef publique

Ensuite, regénérer les stores Java avec les certificats supplémentaires (script generate_stores.sh ; se référer au DIN pour plus d’informations)

5.10.2.4.2. Cas d’une autre PKI

Mettre à jour les stores java avec les certificats supplémentaires à truster.

5.10.2.4.3. Application des stores mis à jour

Rejeu du déploiement en limitant aux groupes ansible [hosts_ingest_external] et [hosts_access_external] et avec le tag ansible update_vitam_certificates.

Exemple:

ansible-playbook ansible-vitam/vitam.yml -i environments/hosts.<environnement> –ask-vault-pass –limit hosts_ingest_external,hosts_access_external –tags update_vitam_certificates