 |
Authentification forte du Coffre-Fort |
|
|
|
 |
L'accès standard Docubase est contrôlé
par un identifiant/mot de passe |
 |
L'authentification forte du Coffre-Fort
est réalisée à l'aide d'un certificat électronique et de son contrôle |
 |
L'authentification d'un utilisateur sur le
frontal web peut s'effectuer par certificat électronique X .509 |
 |
Le contrôle d'accès s'opère alors sur
la base des informations contenues dans le certificat en relation avec un annuaire externe
LDAP |
|
|
|
 |
Confidentialité des transferts Coffre-Fort |
|
|
|
 |
La confidentialité des transferts est
assurée par l'utilisation du protocole sécurisé HTTPS : les transferts concernant les
dépôts ou extractions entre le navigateur et les serveurs http et d'applications WEB
sont cryptés selon un chiffrement symétrique ou asymétrique |
 |
Tous les algorithmes mis en uvre au
cours des opérations de signature sont des algorithmes publiques identifiés de façon
non ambiguë au sein de la signature (algorithme de calcul d'empreinte, algorithme
asymétrique, etc
) |
|
|
|
 |
Gestion des profils Coffre-Fort |
|
|
|
 |
La gestion des profils, des droits, et des
certificats est liée à un annuaire externe LDAP |
|
|
|
Les profils permettent la gestion de
droits fonctionnels différents, avec notamment: |
 |
la gestion de l'espace du coffre-fort
(accès aux différentes bases en fonction du profil) |
 |
les dépôts de documents, l'extraction
des documents, la suppression et l'administration |
|
|
|
 |
Notarisation des journaux d'évènements |
|
|
|
|
Sont notarisés dans un journal: |
 |
tous les accès à l'application GED
Docubase |
 |
toutes les opérations de dépôts
Coffre-Fort et extractions |
 |
toutes les opérations de maintenance dont
l'usage peut avoir une action sur l'intégrité des documents |
|
|
 |
Tous les évènements du journal sont
horodatés par un dispositif d'horodatage |
|
|
|
Le journal fait l'objet d'un
scellement et d'un archivage: |
 |
au minimum une fois par jour |
 |
à chaque démarrage de l'application |
|
|
 |
L'opération de scellement peut s'appuyer
sur une synchronisation de l'horloge du serveur GED sur un serveur de référence et peut
faire l'objet d'un horodatage selon un dispositif interne ou en option sur une autorité
externe (Time Stamping Authority) |
|
|
|
 |
Horodatage des signatures |
|
|
|
|
La fonction d'horodatage des
signatures peut être obtenue de deux façons différentes: |
 |
utilisation de l'heure système de la
machine depuis laquelle la signature est générée (typiquement le module dispatcher).
Dans ce cas l'horloge du serveur doit être synchronisée avec une source de temps de
référence |
 |
obtention d'un jeton d'horodatage conforme
à la RFC 3161 généré par: Un serveur d'horodatage opéré en interne par l'entreprise;
ou Un tiers horodateur TSA (Time Stamping Authority) |
|
|
|
 |
Contrôle d'intégrité des dépôts |
|
|
|
 |
L'intégrité de chaque dépôt est
assurée par un mécanisme de signature électronique |
 |
Lors du dépôt d'un document, une archive
initiale signée et horodatée est crée et archivée |
 |
A l'issue du dépôt une attestation de
dépôt signée est générée et transmise en parallèle par courrier électronique à
l'utilisateur déposant et à un administrateur |
|
|
|
 |
Réversibilité des archives Coffre-Fort |
|
|
|
 |
Le système permet d'extraire en mode
batch et de restituer selon la recommandation EIDE de l'APROGED (format XML) l'ensemble
des documents avec les méta-données et index métier |
 |
Il est possible de faire des sélections
des documents à extraire selon des plages de dates, les valeurs d'index métier ou
l'identité des personnes ayant effectué les dépôts |
|
|
|
 |
Architecture |
|
|
|
 |
CLIENTS: Internet Explorer, Firefox |
 |
SERVEURS: Windows 2003 Server, IBM AIX,
Sun Solaris, Linux Red Hat, Suse, z-Linux |
 |
BASES DE DONNEES: Oracle 9i, Postgre SQL,
IBM DB2 |
 |
SERVEURS D'APPLICATIONS: Tomcat, IBM
Websphere |
|
|
|