Cegid XRP Ultimate | I3 Actualisé le 06/10/2022 |
|||
| Fondations | |||
| La sécurité | |||
| Objectif |
| Pour chaque utilisateur, il est possible de mettre en place une sécurité. Cette dernière est possible à plusieurs niveaux distincts : - la sécurité sur les transactions ; - la sécurité sur les indicateurs ; - la sécurité sur les services ; - les droits d'accès sur les tables ; - la confidentialité d'accès sur les données ; - les droits des utilisateurs ; - les droits d'accès sur tous les paramètres. Ces éléments ont la même finalité : définir l'environnement de travail de chaque utilisateur. Pour faciliter la définition de la sécurité des organisations gérant un nombre important d'établissements, un paramétrage (GTETM), permet la propagation automatique des règles de sécurité définies sur un établissement dit « modèle » sur d'autres établissements dits « cibles ». |
| La sécurité |
| Sécurité sur les transactions, les indicateurs et les services |
| L'objectif de cette fonctionnalité est de définir les transactions, les indicateurs et les services auxquels ont accès les utilisateurs selon les tâches respectives de chacun au sein de l'entreprise. La mise en place de ces droits d'accès peut donc se présenter sous la forme d'une question : Qui fait quoi, où et quand ? Pour répondre et bien définir la sécurité du système, il est recommandé d'analyser les quatre critères suivants : Qui ? Il s'agit de référencer toutes les personnes physiques ou bien des profils fonctionnels. Seules les personnes physiques seront susceptibles de se connecter au système : ce sont les utilisateurs. Quoi ? Un utilisateur ou un profil fonctionnel peut n'avoir accès qu'à un certain nombre de programmes, d'indicateurs ou de services. Pour ce faire : - les transactions sont regroupées en "famille" : ce sont les fonctions. Lors de l'enregistrement d'une transaction dans une fonction, il est possible de limiter les actions à réaliser dans la transaction (sélection, création, modification ou suppression) ; - les indicateurs sont donnés directement à un utilisateur ou à un profil. Il n'y a pas de limitation d'action. L'utilisateur voit ou ne voit pas l'indicateur ; - les services sont également donnés directement à un utilisateur ou à un profil. Il n'y a pas de limitation d'action. L'utilisateur a accès ou non au service. Où ? Il s'agit de référencer des ensembles physiques de postes de travail sur lesquels les utilisateurs peuvent accéder à Cegid XRP Ultimate : ce sont les groupes de postes. Quand ? Il s'agit de définir des périodes d'utilisation (période de validité) : ce sont les vacations. Elles sont attribuées notamment : - à un groupe de postes ; - à un utilisateur ou profil fonctionnel ; - à une transaction. Une fois sa durée de vacation écoulée, un élément n'est plus utilisable. L'ensemble des informations ci-dessus peut être résumé par le schéma suivant : |
| La confidentialité |
| Confidentialité sur les données |
| Fonctionnement |
| 1. Affectation d'une clé de confidentialité pouvant aller de 1 à 4000 pour les enregistrements d'une entité qui sont confidentiels. Les tailles des clés sont définies dans la gestion de modification des entités confidentielles et elles sont modifiables si besoin. 2. Application du code confidentialité aux données Soit par la gestion de création/modification correspondante Soit en utilisant des utilitaires dédiés pour mettre à jour un code confidentialité à un ensemble. 3. Attribuer aux utilisateurs des clés autorisées par entité. 4. Un utilisateur pourra accéder à une entité si la clé de cette dernière fait partie de la liste des clés qui lui sont attribuées. 5. Les données dont la clé est nulle ou 0 sont accessibles par tous les utilisateurs. Vous pouvez ainsi mettre en place la confidentialité uniquement sur les entités que vous souhaitez. Exemple : Un utilisateur "A" a une clé "100" pour l'entité "Compte". L'utilisateur "A" aura alors accès à tous les comptes n'ayant pas de code confidentialité + tous les comptes ayant le code 0 + tous ceux ayant le code "100". |
| Mise en place dans l'interface utilisateur |
| 1. Définir les entités dont la confidentialité est gérée et le nombre de clés à gérer par entité dans la transaction de modification de la confidentialité. 2. Définir les clés confidentielles gérées par entités. 3. Définir les clés pour les entités confidentielles dans les transactions gérant ces entités. 4. Lancer l'utilitaire de recalcul des tables de travail : GTUCNF. 5. Définir les utilisateurs ayant la confidentialité active et ceux qui ne l'ont pas dans les droits de l'utilisateur. Pour cela, il faut jouer avec le droit de confidentialité de l'utilisateur et la variable globale SYSCNF. 6. Définir les utilisateurs ayant la confidentialité gérée par profil. 7. Attribuer des codes par entité aux utilisateurs et aux profils. 8. Si des utilisateurs ont la confidentialité gérée au profil : - définir les délégations entre les profils et les utilisateurs ; - lancer le traitement TCNF pour affecter les codes aux utilisateurs ayant la confidentialité gérée au profil. |
| Mise en place technique |
| Il faut tout d'abord définir le nombre maximum de clés que l'on souhaite gérer par entité. Pour cela il faut : - faire une demande auprès de Cegid qui validera la faisabilité ou non de la demande (trop de clés demandées ==> limites du SGBD) ; - suite à cette demande, Cegid renverra un fichier licence (license.sql) et un fichier de symboles (SYMNB.syc) ; - sur site il faudra : o Mettre en place les fichiers envoyés ; o Lancer le release.sh avec l'option 'c' qui permettra de : * construire le fichier de symbole ; * générer le plan gti_cnf.pln permettant de mettre à jour toutes les tables et de recompiler toutes les procédures touchées en fonction des applications présentes sur le site ; * lancer le plan gti_cnf.pln ; * mettre à jour les valeurs 1 du paramètre AUTCNF avec la taille gérée dans la table. o Dans l'interface utilisateur, modifier la taille gérée pour les entités correspondantes. De plus, la confidentialité est mise en oeuvre au travers de vues. La majorité de ces vues sont simples car associées à des tables ou peu d'entités sont présentes. Mais pour certaines tables, cette mise en oeuvre nécessite l'utilisation d'une table de stockage des codes de confidentialité ( nom de la table = table origine + wc => ocecrwc). Ces tables de travail sont mises à jour dès que la globale SYSCNF est activée ou qu'au moins un utilisateur a la confidentialité active. Ces tables peuvent ne pas être mises à jour. Pour cela, elles sont listées comme occurrence du paramètre MAJCNF et la valeur testée 1 doit être à N. Sous Oracle, il est possible d'utiliser des vues spécifiques client. Pour cela, il faut modifier le symbole correspondant au public synonyme et recompiler le script du public synonym. Exemple : Pour modifier la vue oetieci par oetie_spe : - Mettre oetie_spe dans la valeur du symbole syn_oetiec ; - Faire un plan avec la ligne suivante : ode syn csoetiec.obj - Lancer un gtuvalid.exe pour revalider tous les objets invalides. |
| Contraintes techniques |
| - Si le nombre de clés demandé est inférieur à la valeur actuelle, il faut vérifier au préalable que le nombre géré est bien inférieur au nombre demandé. Pour cela, dans la transaction MCNF, vérifier et éventuellement modifier la taille gérée pour l'entité. - Le nombre maximum de clés gérées pour une entité est de 4000. Mais il n'est pas possible de gérer les 4000 clés pour toutes les entités. En effet dans ce cas, on atteint les limites des SGBD. - La confidentialité ne peut être mise en oeuvre que si les tables de travail utilisées ont été pré-taillées et si l'espace pour les accueillir a été prévu (Taille généralement non négligeable). Ces tables de travail contenant une image des codes d'accès, une modification de ces codes au niveau des entités n'est pas répercutée. Pour mettre à jour ces tables de travail, il existe un utilitaire. |
| Utilitaire associé à la confidentialité |
| Pour recalculer les tables de travail lors : - de la mise en place initiale ; - suite à une modification de la valeur des clés dans les entités ; - suite à une désactivation momentanée de la confidentialité un utilitaire de recalcul global de ces tables existe : GTUCNF Cet utilitaire qui peut être long à l'exécution : - doit être lancé avec la confidentialité activée. - ne doit pas être lancé en concurrence avec des accès aux tables concernées. |
| Transactions associées à la confidentialité |
| Les transactions utiles à la gestion de la confidentialité sont : * La gestion des modifications des entités confidentielles : elle permet de définir les entités confidentielles gérées et de modifier la taille gérée par entité. * La gestion des clés de confidentialité : elle a pour but d'associer un libellé à chaque clé confidentielle. * La consultation de l'historique des modifications des clés des entités confidentielles.. * La gestion des droits utilisateurs pour activer la confidentialité à l'utilisateur. * La gestion des variables globales pour activer la confidentialité de manière globale. * La gestion de la confidentialité par utilisateur pour associer des clés de confidentialités soit à un profil soit à un utilisateur individuel sur une entité. * La gestion de la confidentialité par entité pour donner des utilisateurs à des entités sur des clés. * Le traitement de génération des codes de confidentialités qui met à jour les associations entité, clé et utilisateur individuel. Il est utilisé quand nous décidons de gérer les clés de confidentialités au profil. Comme pour la sécurité, ce traitement suit la hiérarchie de délégation entre profil et utilisateur pour mettre la clé de l'entité à l'utilisateur final. |