T-SAS: T24 – Scramble, Archiving and Subset 31/03/2017 T-SAS: T24 – Scramble, Archiving and Subset QUALITY PARTNER FOR YOUR EXPANSION

Pourquoi l’archivage? (1/2) Réduire les coûts de stockage en déplaçant d’anciennes données hors ligne. Accroître l’efficacité en réduisant l’empreinte de données actives. Améliorer les scénarios de backup – Les petits paquets de données sont plus faciles à sauvegarder. Rapidité de temps de restauration – Des petits paquets de données sont plus rapides à restaurer. Améliorer les performances – Un petit ensemble de données rend d’indexation plus rapide et réduit les coûts d’extraction .

Pourquoi l’archivage? (2/2) Répondre aux besoins de conformité – Les données sont préservé pour un accès ultérieur et sauvegardé. Pour conserver la performance (requête et COB) sous control après Go Live au-delà d’une période les données augmentent progressivement. Pour être en mesure de faire une copie d’un environnement (copie de production) plus rapidement et en réduisant sa taille Réduire de mise à jour et du temps de conversion des données.

Pourquoi l’archivage? 40% de TCCA peut être une estimation prudente! “Avec des taux de croissance supérieurs à 125% , les organisations sont confrontés à deux options: continuer à croître l’infrastructure ou développer des procédés pour séparer les données dormantes des données actives.” Source: Meta Group 2008

Pourquoi l’archivage? Coût Performance Gestion Lorsque la BDD augmente du Hardware supplémentaire est nécessaire pour maintenir un niveau de service. ex: broches supplémentaires pour fournir IOPS pour les anciennes données. Coût Certaines instructions SQL peuvent ne pas bien évoluer (scans complets). De plus en plus d’attention dans les réglages SQL/ les réglages des requêtes/ réglages du COB est nécessaire sur de très grandes tables Performance Une base de données ne doit pas devenir un “vidage de données” Les très grandes BDD sont difficiles à gérer. Sans une stratégie d’archivage dès le 1er jour, il est difficile de gérer la croissance de la base de données sur une période de temps. Gestion

Raisons Business pour garder les données d'archives Nombreuses copies de production Exigences de conformité Analyser les problèmes Temenos peut demander d’anciennes données pour analyser des problèmes Core/Bugs Mises à jour d’applications Les équipes projet ont besoin de nombreux environnements de test et de développement Banque Centrale/Organisme gouvernemental de conservation de données Données doivent être conservées pour un potentiel audit Augmentation de la croissance due à une plus grande footprint

Augmentations des coûts opérationnels Symptômes Les utilisateurs applicatifs se plaignent que le système est lent lors: Lancement des requêtes online et la période financière de liquidations Saisie des transactions et le traitements des paiements Augmentation le temps du COB et la génération de rapports Augmentation des temps des COBs hebdomadaires/mensuels/trimestriels. Augmentations des coûts opérationnels Plus importantes licences hardware et software et coût de support Cycles de développement et de test plus long Temps de main d’œuvre et d’effort pour les tâches administratives du système Temps de maintenance à long terme pour gérer les processus de backup et de clone Effectifs supplémentaires nécessaires pour gérer adéquatement un environnement plus important.

Base de données De Production …cela continue à ajouter Personnes Problème potentiel: croissance de la base de données!!! …cela continue à ajouter Personnes Processus Technologie …et cela continue de diminuer Performance Disponibilité Temps pour d’autres projets Base de données De Production

Approches traditionnelles Ajouter plus de capacités Impact de la ligne de fond Coût continu incontrôlé Instaurer des applications rigoureuses/réglages de la base de données N’aborde pas directement la croissance des données, mais le cache Atteint le point de rendements décroissants Suppression des données (c.à.d. Purge) Les questions juridiques et de rétention Les données peuvent être nécessaires pour le Datawarehouse Développement interne Entreprise complexe Application spécifique Support/Mise à jour/Maintenance

Archivage - Faits Jusqu’à 80% des données dans la base de données OLTP de plus de 2 ans ne sont plus nécessaires pour l’activité quotidienne de la société. Les frais administratifs pour le stockage de 1To sont cinq à sept fois plus élevés que les coûts de stockage (Dataquest/Gartner). Suppression des anciennes transactions de la base de données active permettra de réduire les coûts et augmenter les performances des applications critiques. La majorité des banques ne contrôlent pas la croissance de la base de données sur une base quotidienne. Difficile de mettre en place l’archivage après 2 ans de croissance de la BDD, tant le temps d’arrêt est nécessaire pour le processus d’archivage avec la taille de la base de données.

Effet multiplicateur Besoin actuel de données = Taille de la base de données de production + tous les clones dupliqués 200GB Test Développement Control de qualité 200 GB Production 1200GB Total 200GB Backup Disaster Recovery 200GB 200GB Formation

Archivé / purge de la base de données Stratégie d’Archivage Archive Données Actuelle 1+ ans Historique Actif 2-3 ans Base de données De production Base de données des archives de rapports Archive Archivé / purge de la base de données Base de données de test

Réduit la quantité de données dans la base de données d’application Archivage actif Accès aux données (localisation, navigation, recherche) Base de données de production Base de données d’archive Fichiers archivés Fichiers archivés purge Réduit la quantité de données dans la base de données d’application Supprimer les données obsolètes ou peu utilisées Maintenir un “contexte business” de données archivées Purger les fichiers archivés régulièrement pour en garder le contrôle Permet aux utilisateurs un accès facile aux informations archivées Voir, rechercher et restaurer selon les besoins Soutien données et les stratégies de gestion de stockage de la banque

Archivage - Qu'est-ce qui est disponible aujourd'hui L’archivage est une solution orientée T24, cela réduit le nombre de fichiers Live ou de fichiers HIS en déplaçant les enregistrements en fichiers $ARC. Le processus actuel d’archivage standard et les paramètres couvrent uniquement une partie des fichiers T24 Core. Pour archiver les fichiers locaux et les fichiers Core, non inclus dans l’archivage standard (tables liées aux frais, tables liées aux AM, tables AA, etc) dont un développement local supplémentaire est nécessaire. Les tables sont classées en 3 catégories Tables Core (couvertes par le processus archivage Core) Nouvelles tables Core ( non couvertes par le processus d’archivage Core, nouveau dev local) Tables locales (non couvertes par le processus d’archivage nouveau dev local)

Archivage - Qu'est-ce qui est disponible aujourd'hui DE.O.HISTORY ../bnk.arc/de/DE.O.HISTORY$ARC Données On-line Archive Données On-line Espace vide

Archivage - Limitations actuelles Le processus actuel d’archivage ne couvre pas tous les fichiers Core qui croient. Cette fonctionnalité est limitée dans les anciennes version T24. Le processus d’archivage existant est une application autonome qui déplace les données LIVE/HIS vers les tables $ARC mais rien d’autre. Ce n’est pas une solution pour une application autonome. Les banques ne peuvent pas l’utiliser tel quel. Lorsque l’archivage est fait, par défaut, il ne réduit pas la taille de la DB mais elle augmente, car l’espace vide n’est pas rendu par défaut. L’accès aux données archivées est transparent pour l’utilisateur, car ils ont besoin d’écrire des requêtes spécifiques pour accéder aux données des tables $ARC. Le paramétrage est limité (uniquement basé sur la Date), qui est une limitation énorme vu que de nombreuses tables n’ont pas le champ DATE.TIME (comme les concat files, fichiers live, etc.). Aucunes techniques de base de données ne sont utilisées dans l’ensemble du processus d’archivage. L’ensemble du processus d’archivage est manuel (configuration, l’exécution, le déplacement des tables, l’exécution du redimensionnement/réorganisation pour récupérer de l’espace, l’accès aux données ARC, etc.) Les fichiers $ARC ont coutume de ne pas être lors de la mise à jour de T24. Ainsi ces fichiers seront obsolètes après la mise à jour T24.

SAS.ARCHIVE.PROFILE

SAS.ARCHIVE.PROFILE

Archivage – Notre solution Couvre le processus d’archivage pour toutes les plus grandes tables principales Core T24. La solution d’archivage n’est pas uniquement pour les tables mais aussi pour les répertoires. 2 étapes du mécanisme de configuration qui permettent l’archivage de toute table locale avec toutes les options de filtre complexe. Permet toutes tables dépendantes locales d’être archivées/purgées à travers le processus d’archivage Core Flexibilité pour stocker les données archivées au sein d’un même TABLESPACE ou différents TABLESPACE ou même différents SCHEMA Scripts automatisés pour récupérer l’espace libre/vide lors du rétrécissement de bases de données Temps d’arrêt nécessaire nul ou minime lors le processus de la contraction de la base de données. Ecran utilisateur unique pour la définition de service, Contrôle et Surveillance du service d’archivage. L’accès transparent aux données depuis les tables archivées est transparant des tables Cores ou locales. Un ensemble de tables prédéfinies sont purgées, cette liste peut être modifiée localement

Archivage – Notre solution Utilisation optimale de stockage Conserver uniquement les données nécessaires dans un stockage à grande vitesse (ex: SDD), ce qui est coûteux. Retrait des données les moins accédées pour diminuer le coût de stockage de disque. Contrôle la croissance de la DB et dépenser moins sur l’infrastructure de stockage. Mise à jour du logiciel - Supporté La conversion automatique de temps d’exécution se produira, ce qui permet de convertir le format d’anciens enregistrements pour la release T24 actuelle. Aucune conversion nécessaire, ce qui est consommateur de temps. Pour lire les données archivées, une API standard est fourni qui peut être utilisé dans le développement local. Pas d’énorme problèmes de performance et c’est un simple champ de mapping de l’ancienne version T24 vers la nouvelle version T24.

Archivage – Reprise / Reorg / Réduction Utiliser Reorg pour optimiser les tables, les index et l’espace des tables après archivage: La plupart des bases de données relationnelles supportent la Reorg ONLINE. Le support Online de rétrécissement sous Oracle pour les tables XML et ses objets associés (index, segment LOB, etc.) DB2 supporte une REORG Online pour une DB XML à partir de DB2 9.7 Il n’est pas nécessaire d’arrêter la DB durant la REORG, les grandes tables peuvent être traitées en parallèle pour accélérer le processus. Il est possible de redimensionner une DB jBase pour réduire la taille des tables. Après la performance de la Reorg sera améliorée pour ces tables TABLESPACE TABLESPACE Temporary DATAFILE Temporary TABLESPACE Free DATAFILE 1 DATAFILE 2 TABLE A Part 1 of 2 TABLE B TABLE C Part 2 of 2 TABLE D Free DATAFILE 1 Free DATAFILE 1 DATAFILE 2 TABLE A Part 1 of 2 TABLE B TABLE C Part 2 of 2 TABLE D Free Free TABLE A TABLE B TABLE C TABLE D Copy of TABLE A Copy of TABLE B Copy of TABLE C Copy of TABLE D

Accès aux données archivées - Routines standards fournis pour accéder aux données archivées à partir de requêtes existantes. Elles liront les données archivées ou Live sur la base de la date indiquée. - Requêtes standards qui sont fournies ont été spécifiquement écrites pour les données archivées - Un ensemble d’API sont fournies pour prendre en compte les développements locaux avec une documentation claire. Fichiers/applications d’Interface de nettoyage - Il n’y a pas par défaut un nettoyage automatique pour les fichiers interfaces T24/fichiers de log/fichiers OFS. - Actuellement l’accumulation de données dans des dossiers partagés par les serveurs d’application T24 (NFS/GPFS) n’est pas traité. En conséquence, la taille totale et le nombre d’INODE se développent considérablement. Un mécanisme d’archivage empêche la croissance incontrôlée de ces fichiers. - Le service d’archivage va scanner les dossiers spécifiques fondés sur un ensemble de règles définies dans un fichier de paramètres. Le service a la possibilité de supprimer les anciens fichiers ou de créer des archives compressées. Exécutés quotidiennement, la quantité de données dans les dossiers sélectionnés se stabilisera. - Cela permet de garde les fichiers d’application propre et contrôlé, ce qui permet de réduire les temps de backup et de restauration ainsi que les besoins de stockage.

STOCKAGE DE DONNÉES ARCHIVÉES - Plusieurs options sont disponibles dans notre solution pour stocker les données archivées. - Les données archivées peuvent être conservées sous forme de fichiers de hachage jBase dans un système de fichiers distinct. Ce répertoire peut être ignoré durant les backups et les restaures. - Les données archivées peuvent être conservées dans un autre TABLESPACE si T24 tourne sous des serveurs ORACLE/DB2/SQL. Ce TABLESPACE peut être conservé dans des disques moins coûteux et peut être ignoré dans les backups et les restaures. - Les fichiers de données archivés peuvent être conservés dans un autre schéma au cas où T24 tourne sur un server ORACLE / DB2 / SQL. Ce schéma peut être conservé sur des disques moins coûteux et peut être ignoré lors de backup et de restaure. - Les fichiers de données archivés peuvent être conservés dans une base de données différentes et accessible via un environnement T24 différent.

Architecture T24 PRODUCTION UTILISATEUR PRODUCTION UTILISATEUR WAS WAS MQ/TCPIP MQ/TCP T24 T24 PROD TS Scénario normal PROD DB

Menu Restreint – Données Live Menu restreint – Données d’Archive ARCHIVE STORAGE – TABLESPACE OPTION UTILISATEUR ARC PRODUCTION UTILISATEUR WAS WAS Menu Restreint – Données Live Menu restreint – Données d’Archive MQ/TCP MQ/TCP T24 T24 PROD TS Libre Après le scénario d’Archive ARC TS PROD DB

Stockage des données archivées – option TABLESPACE Création d’une autre TABLESPACE ne compromet en aucune façon la sécurité de la base de données, dès sa mise en place qui s’appuie entièrement sur les fonctionnalités de base de données et suivre la conception T24. Un TABLESPACE est un ensemble de volumes sur des disques qui possèdent les ensembles de données dans lesquels les tables sont effectivement stockées. Tous les tableaux sont conservés dans les TABLESPACE. Un TABLESPACE peut contenir une ou plusieurs tables. Avantages: //Toutes les données T24 se trouvent sur la base de données. //Résistance à la corruption de données. //Capacité à utiliser les fonctions des bases de données comme la compression TABLESPACE/le cryptage pour de plus petites tailles de bases de données. //Le TABLESPACE peut résider sur des disques séparés moins coûteux (SATA); d’où, cela n’affectera pas les performances de la base de données principale. //Les backups quotidiens n’incluent pas ces TABLESPACE.   Inconvénients: //La taille du TABLESPACE va continuer à croître. En conséquence, une autre procédure de purge avec une période de rétention des données archivées doit être élaborée afin de garder la taille du TABLESPACE stable sur le long terme. //Le script actuel de backup doit être modifié pour exclure les TABLESPACE ARC du processus de backup quotidien.

Menu Restreint– Données Archivées Menu Restreint– Données Live PRODUCTION UTILISATEUR ARC UTILISATEUR Menu Restreint– Données Archivées Menu Restreint– Données Live WAS WAS MQ/TCP MQ/TCP T24 T24 Libre PROD TS ARC TS Après le scénario d’Archive DBLINK / FEDERATED SERVER PROD DB ARCHIVE DB

Stockage de données archivées – DB indépendantes Les fichiers ARC peuvent être conservés sur un serveur à distance et accessible depuis le serveur de production via des options de connexions comme dbLink ou DB2 Federated ou JRFS (jBase remote file system). Avantages: //Pas de changement dans les scripts courants pour le backup et le restaure de la DB de production. //Fonctionne comme une base de données indépendante, l’administration de DBA sera plus facile. //La sécurité des données n’est pas compromise à la fois sur la DB de production que la DB d’archivage sur la même instance DB de production. //Fonctionne de manière transparente sur DB2/ORACLE/JBASE. Pas de patchs majeurs, de configuration, changements nécessaires à la configuration serveur fédéré/DBLINK/JRFS. //La DB d’Archive sera sur un système de fichiers séparé sur des volumes de disques moins coûteux (disques SATA), de sorte qu’il sera un système à faible coût. //Une même DB d’Archive peut être partagée entre de nombreux environnements T24 ce qui permet d’éviter l’utilisation de stockage pour chaque environnement.  Inconvénients: //La structure des données T24 sera fragmentée, une partie sera stockée sur la DB de production et une autre partie sur une autre DB. //La création de nouvelles tables est possible sur une DB distante T24, les tables peuvent être déplacées manuellement vers une DB distante puis la liaison doit être établi entre la DB de production et la DB distante. //La performance sera affectée (5 fois plus lent par rapport à la conservation des données sur la même DB). //La création d’Index ne fonctionne pas depuis un serveur fédéré vers une DB distante.

Menu restreint – Données Live Menu restreint – Données Archivées ARCHIVAGE - sous forme de fichiers J4/JR PRODUCTION UTILISATEUR ARC UTILISATEUR WAS WAS Menu restreint – Données Live Menu restreint – Données Archivées MQ/TCP MQ/TCP GPFS / NFS / JRFS T24 T24 ARC Files as J4/JR Libre PROD TS Après le scénario d’archive PROD DB

Stockage de données archivées – DB indépendante Avantages: //Fichiers structurés pour chaque table ARC. En conséquence, il serait plus facile et rapide de restaurer et de travailler avec uniquement les données nécessaires pour le Business. //Possibilité de faire des fichiers jBase distribués. Par exemple, il est possible de faire un fichier distribué par date (par exemple, par années pour les fichiers STMT et de Delivery), ainsi chaque fichier contient les enregistrements regroupés par année. Les plus anciennes parties de ces fichiers peuvent être mis sur bande puis supprimées. Sur demande, la partie du fichier peut être facilement récupérer et utilisée par T24 par requêtes. Il peut y avoir jusqu’à 254 parties définies par fichier. Donc la purge de fichiers sera plus facile . //La taille de fichiers sera 50% plus petite en comparaison des tables DB, car il n’y aura pas un quelconque format XML. //Simple mécanisme de hashage de fichiers, pas de licence supplémentaire nécessaire. Facile à administrer. //Pas de changements dans les scripts de backup et de restore de DB, peut être facilement géré par des options tar / gz.  Inconvénients: //La structure de données T24 sera fragmenté, une partie sera stockée sur DB, et une partie sur les tables de fichiers. //Pour la distribution de fichiers et la gestion des parties des fichiers, une procédure doit être développée en incluant: La préparation de routines DISTRIB pour les fichiers ARC. La préparation d’un script sur base annuelle pour compresser et mettre sur bandes les plus anciens fichiers pour tous les fichiers ARC concernés sur la base de période de rétention des archives, et de les remplacer sur les disques par des parties de fichiers vides. Définir une procédure pour restaurer les parties de fichiers et les déposer temporairement sur disque, ainsi l’utilisateur sera en mesure d’interroger les anciennes données T24. //Risque de corruptions de données..

Menu Restreint – Données Live Menu Restreint – Données Archivées ARCHIVAGE – DRIVER/ACCES DW UTILISATEUR ARC PRODUCTION UTILISATEUR Menu Restreint – Données Live WAS EXCEL / CRYSTAL REPORTS / BUSINESS OBJECTS / TODD Menu Restreint – Données Archivées MQ/TCP DRIVER / ETL T24 T24 Connexion jRFS Après scénario d’archive PROD TS Free ARCHIVE DB PROD DB

SCRAMBLING

Data Masking - Scrambling Introduction Le but principal de cet outil est de scramblé une base de données T24 tout en maintenant l’intégrité des données de la plate-forme. L’anonymisation des données sensibles comme (l’adresse des clients, nom, les champs KYC, et des portefeuilles reconnaissables) dans diverses tables sera réalisée par cet utilitaire.   L’objectif d’un tel exercice est de fournir une base de données « scramblé »en dehors du pays hôte ou accueillir l’environnement scramblé mais permettre un accès transfrontalier à cet environnement. L’outil a été développé en langage de programmation T24 (j-basic) et est conçu pour fonctionner en mode multi-thread, en maximisant l’utilisation des ressources du serveur. Le Data masking est un mécanisme préconstruit qui peut être exécuté pendant le processus SUBSETTING ou STANDALONE. Masquer les données sensibles dans les bases de données de non-production. Entièrement piloté par des paramètres. Scrambler ou crypter toutes les données dans une table T24 (standard ou non-standard).

Data Masking - Scrambling Méthodes de masquage Encryptions intégrées Simple algorithme de Scrambling (masquage du nom des clients par XXX) Réglage automatique de la longueur des champs. Mise à jour facilement configurable des fichiers concat pour les champs sensibles Facile extension pour inclure vos propres méthodes. Désidentifier les données sensibles Information sur les employés Information sur les clients Information des fournisseurs Parfait pour la formation, le testing, les bases de données de développement. Bon pour le développement offshore. Paquets précompilés Basé sur les meilleures pratiques suivies par la plupart des banques, la majorité des champs applicatifs sensibles sont mappés par défaut. Champs supplémentaires doit être mappé comme champs LOCAL.REF, tous les champs sensibles core sont déjà mappés. Couvre tous les principaux modules T24 dans le paquet pré-construit.

SAS.SCRAMBLE.PROFILE Identifie automatiquement tous les fichiers associés tels que $NAU, $HIS, $ARC ou $SIM sont également scramblés. Prise en charge de valeurs aléatoire tels que la DATE, MOIS, ANNEE ou autres listes de valeurs depuis le répertoire SAVEDLISTS Prend en charge l’encryption, l’encryption par défaut est XOR. Une encryption complexe peut être faite en utilisant l’option SUBROUTINE Règle la longueur automatiquement par dictionnaire ou par longueur de la valeur originale. Si PC file est disponible pour une application donnée, alors le contenu de PC file sera également scramblé. Concat Files configuration, which will be updated automatically

Scrambling sample

Data Masking – Scrambling dynamique / Le scrambling dynamique permet de MASQUER/SCRAMBLER les informations sensibles à la volée dans la base de données de production. / Au niveau de la vue utilisateur, les informations scramblées en mode SEE sur les champs sensibles. / Utilise la même fonctionnalité SAS.SCRAMBLE.PROFILE, avec une API simple qui appelle un scrambling dynamique disponible sur tous les écrans VERSION. Parfait pour les utilisateurs externes, entrepreneur, employés et gestionnaires de comptes pour accéder au contrôle aux données sensibles sur la base de données de production.

Audit jBase et contrôle d’accès Monitorer les privilèges d’accès Il y a beaucoup d’utilisateurs privilégiés inconnus dans une banque. Les administrateurs système, les utilisateurs ayant accès à du contenu sensible notamment sur ces comptes où l’activité devrait être suivi de près, comme l’environnement de production. Pour savoir ce qu’ils font vraiment de leurs accès, il est obligatoire de suivre leurs activités. Suivre les partenaires externes Certaines banques ont plus d’utilisateurs externes que d’utilisateurs internes. Ils ne peuvent pas les contrôler avec leurs politiques courantes: le suivi et le contrôle de leurs activités est une obligation. Respecter les normes industrielles et internationales L’audit de conformité est une des tâches des plus pénibles de nombreuses banques. Les régulateurs externes du gouvernement ou d’organisations internationales peuvent vérifier qui est conforme aux normes obligatoires. Les données sensibles doivent être protégées et tout accès en arrière plan des sources de données doit être étroitement surveillé et contrôlé.

Audit jBase et contrôle d’accès Accès T24 L’accès aux applications T24 est complètement contrôlé par le système de configuration défini au niveau applicatif du contrôle d’accès, appelé (SMS). La mise en place du USER.SMS.GROUP qui contrôle la méthode d’accès pour chaque utilisateur défini dans le système et qui permet l’enregistrement au niveau USER pour s’assurer que toutes les activités des utilisateurs sont enregistrés dans la table F.PROTOCOL, qui peut être utilisé plus tard à des fins d’Audit. Accès TAFC / JBASE Actuellement il n’y a pas de système de contrôle d’accès/de système de logging par défaut pour TAFC/JBASE. JBASE agit actuellement comme une base de données ainsi que l’environnement d’exécution pour T24. Permettre l’accès au jshell signifie que les utilisateurs peuvent être en mesure d’agir en arrière plan sur les données T24, en particulier cela devient difficile lorsque des bases de données externes comme DB2, MSSQL sont utilisées, aucune commande Unix peut protéger les données. Il s’agit d’un des risques majeurs pour la banque et l’Audit élèvera aussi une objection. Pour contre cela, ITSS a développé un wrapper pour jshell qui permettra de contrôler les restrictions d’accès pour les utilisateurs et aussi enregistrera toutes les activités réalisées au niveau Jshell.

Configuration du contrôle d’accès F.TAFC.ACCESS.PARAM – SYSTEM Le record SYSTEM aide à enregistrer toutes les commandes définies par défaut. L’utilisateur a la possibilité d’avoir des accès complets, mais toutes les opérations seront enregistrées par défaut. Field 1 – Liste de commandes séparées par des virgules seront enregistrées dans la table F.TAFC.AUDIT.LOG. Ex: JED,BASIC,CATALOG Si le record SYSTEM n’existe pas – Une liste par défaut est utilisée: ED,JED,EED,EJED,EEDIT,EDIT,BASIC,CATALOG,DECATALOG,COPY,LOGOFF,JKILL, CREATE,SELECT,LIST,CLEAR,DELETE Il est conseillé d’ajouter uniquement les commandes sensibles dans cette liste pour éviter l’engorgement inutile.

Configuration du contrôle d’accès F.TAFC.ACCESS.PARAM – SYSTEM ID est le nom de connexion de l’utilisateur Unix. Si l’enregistrement est introuvable – la commande n’est pas vérifiée pour restriction, l’accès complet est disponible pour l’utilisateur mais toutes les opérations seront enregistrées par défaut. Field 1 – fichiers restreints, séparés par des virgules (il est aussi possible de restreindre un champ) ex: FBNK.ACCOUNT,FBNK.CUSTOMER ex: FBNK.CUSTOMER>SHORT.NAME,FBNK.ACCOUNT>CURRENCY Peut être spécifié comme ALL, ainsi l’utilisateur n’aura pas le droit de faire quoi que ce soit sur l’une des tables défines dans le VOC.. Field 2 – commandes restreintes, séparées par une virgule ex: JED,LIST,SELECT. Peut être spécifié comme ALL, ainsi aucune commande n’est autorisé pour cet utilisateur. Field 3 – fichiers d’exception, séparé par une virgule ex: FBNK.STMT.ENTRY,FBNK.CATEG.ENTRY Utilisé lors qu’il est précisé ALL dans le champ 1. Field 4 – commandes d’exception, séparé par une virgule ex: LIST,SELECT,SORT Utilisé lors qu’il est précisé ALL dans le champ 2

Exemple de TAFC.ACCESS.PARAM t24oper ----- Identifiant Unix 001 FBNK.CUSTOMER>SHORT.NAME,FBNK.ACCOUNT>CURRENCY 002 LIST,JED 003 004 t24admin 001 FBNK.ACCOUNT 002 All 004 SELECT,JED t24support 001 All 002 003 FBNK.STMT.ENTRY,FBNK.CATEG.ENTRY

Journal d'audit - F.TAFC.AUDIT.LOG Il s’agit d’un fichier de log avec les détails suivants. ID – format est Date_Time_PortNumber_LoginName Field 1 – nom de la routine Field 2 – clé d’enregistrement Field 3 – date & heure Field 4 – commande actuelle exécuté Field 5 – identifiant utilisateur Field 6 – adresse IP Field 7 – host name Field 8 – terminal Field 9 - environnement

Exemple TAFC.AUDIT.LOG 20120309_11-35-10_4080_t24support 001 jsh.b -> jsh.b -> jsh.b 002 jutil_jsh__dev_pts_106 003 09 MAR 2012 11:35:10 004 LIST-ITEM F.TAFC.ACCESS.PARAM ‘t24oper' 005 t24support 006 (P06412) 007 t24prodserver 008 /dev/pts/106 009 t24prod 20120309_12-08-36_4081_t24oper 002 jutil_jsh__dev_pts_99 003 09 MAR 2012 12:08:36 004 LIST FBNK.ACCOUNT 005 t24oper 006 192.168.56.101 008 /dev/pts/99 009 t24test - Both F.TAFC.ACCESS.PARAM and F.TAFC.AUDIT.LOG will be kept in jbase hash file and restricted permission (write) will be given only for ADMIN or ROOT. This will avoid tampering this configuration tables by other unix users

SUBSETTING

Archivage – Notre approche Scoping - 5 jours - Analyser la base de données pour la croissance de la DB et des grandes tables. - Analyser au niveau des répertoires applicatifs et des fichiers Interface - Décider où placer les données archivées - Estimer l’économie de stockage, le temps d’archivage, la période de rétention, TCO et Pilotage de la salle de Conférence - 10 jours - Configurer la table de paramètre et son trail run - Corriger le relancement de l’archivage/de la récupération/du scrambling - Créer accès aux données pour l’archivage - Formations des administrateurs sur l’archivage Affiner/UAT - 10 jours - Test UAT avec validation business - Approuver la configuration des paramètres - Valider COB / online - Fin de mois / fin d’année et testing Déploiement - 5 jours - Déploiement en Production - Exécution en Production - Support

Méthodologie Scoping Support post Live Configurer la table de paramètres et trail run Happy Client Déploiement en production et Formation Corriger relance de archivage / récupération / scrambling COB validé/ online Stratégie d'archivage et stockage des données Tests UAT avec validation de l'utilisateur business

Merci pour votre attention! Nous contacter ITSS 109, rue du Pont du Centenaire CH – 1228 Plan-les-Ouates Suisse Tel: + 41 22 706 20 80 www.itssglobal.com Merci pour votre attention! QUALITY PARTNER FOR YOUR EXPANSION