QUALITY PARTNER FOR YOUR EXPANSION T-SAS: T24 – Scramble, Archiving and Subset.
-
Upload
dieudonnee-lefort -
Category
Documents
-
view
130 -
download
16
Transcript of QUALITY PARTNER FOR YOUR EXPANSION T-SAS: T24 – Scramble, Archiving and Subset.
QUALITY PARTNER FOR YOUR EXPANSION
T-SAS: T24 – Scramble, Archiving and Subset
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 .
• 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.
• 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.
2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011
Données actuelles
Anciennes Données
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?
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
Pourquoi l’archivage?
Raisons Business pour garder les données d'archives
6
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
Symptômes
• 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.
Les utilisateurs applicatifs se
plaignent que le système est lent lors:
• 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.
Augmentations des coûts opérationnels
7
Problème potentiel: croissance de la base de données!!!
8
…cela continue à ajouterPersonnesProcessusTechnologie
…et cela continue de diminuerPerformanceDisponibilitéTemps pour d’autres projets
Base de donnéesDe Production
9
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
10
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
11
200 GB Production
200GB Backup
DisasterRecovery
200GB
200GB Test
200GB Développement
200GB Control dequalité
Besoin actuel de données = Taille de la base de données de production + tous les clones dupliqués
1200GBTotal
200GB
Formation
Stratégie d’Archivage
ArchiveArchive
12
DonnéesActuelle
1+ ans
HistoriqueActif
2-3 ans
Base de donnéesDe production
Base de donnéesdes archivesde rapports
Archive
Base de donnéesde test
Archivé / purge de la base de données
Archivage actif
13
Accès aux données (localisation, navigation, recherche)
Base de données de production
Base de données d’archive
Fichiersarchivés
Fichiers archivés
• 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
purge
14
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)
15
Archivage - Qu'est-ce qui est disponible aujourd'hui
../bnk.arc/de/DE.O.HISTORY$ARCDE.O.HISTORY
ArchiveDonnées On-line
Données On-line
Espace vide
16
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
17
SAS.ARCHIVE.PROFILE
19
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
20
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:
DATAFILE 1
DATAFILE 2
TABLE APart 1 of 2
TABLE B
TABLE CPart 1 of 2
TABLE APart 2 of 2
TABLE CPart 2 of 2
TABLE D
Free
DATAFILE 1
DATAFILE 2
TABLE APart 1 of 2
TABLE B
TABLE CPart 1 of 2
TABLE APart 2 of 2
TABLE CPart 2 of 2
TABLE D
Free
TABLESPACETABLESPACE
DATAFILE 1
Free
Free
TABLE A
TABLE B
TABLE C
TABLE D
Temporary DATAFILE
Temporary TABLESPACE
FreeCopy of TABLE A
Copy of TABLE B
Copy of TABLE C
Copy of TABLE D
• 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
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.
23
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
24
T24 T24
PROD TS
MQ/TCPIP
PROD DB
WAS WAS
PRODUCTION UTILISATEUR PRODUCTION UTILISATEUR
Scénario normal
MQ/TCP
ARCHIVE STORAGE – TABLESPACE OPTION
25
T24 T24
PROD TSARC TS
MQ/TCP
WAS WAS
PRODUCTION UTILISATEUR UTILISATEUR ARC
Après le scénario d’Archive
Libre
Menu restreint – Données d’Archive
Menu Restreint – Données Live
MQ/TCP
PROD DB
26
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.
T24 T24
PROD TS ARC TS
MQ/TCP
WAS WAS
PRODUCTION UTILISATEUR ARC UTILISATEUR
Après le scénario d’Archive
Libre
Menu Restreint– Données Archivées
Menu Restreint–
Données Live
MQ/TCP
PROD DB ARCHIVE DB
DBLINK / FEDERATED
SERVER
28
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.
29
T24 T24
PROD TS
ARC Files as J4/JR
MQ/TCP
WAS WAS
PRODUCTION UTILISATEUR ARC UTILISATEUR
Après le scénario d’archive
Libre
Menu restreint – Données Archivées
Menu restreint – Données Live
MQ/TCP
PROD DB
GPFS / NFS / JRFS
ARCHIVAGE - sous forme de fichiers J4/JR
30
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..
Stockage de données archivées – DB indépendante
ARCHIVAGE – DRIVER/ACCES DW
31
T24 T24
PROD TSARCHIVE
DB
MQ/TCP
WAS
PRODUCTION UTILISATEURUTILISATEUR ARC
Après scénario d’archive
Free
Menu Restreint – Données Live
PROD DB
EXCEL / CRYSTAL REPORTS / BUSINESS
OBJECTS / TODD
DRIVER / ETL
Connexion jRFS
Menu Restreint – Données Archivées
SCRAMBLING
33
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
34
Méthodes de masquageEncryptions intégréesSimple 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ésInformation sur les clientsInformation 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.
Data Masking - Scrambling
Concat Files configuration, which will be updated automatically
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é.
Identifie automatiquement tous les fichiers associés tels que $NAU, $HIS, $ARC ou $SIM sont également scramblés.
SAS.SCRAMBLE.PROFILE
Scrambling sample
37
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.
Data Masking – Scrambling dynamique
Monitorer les privilèges d’accèsIl 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 externesCertaines 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 internationalesL’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é.
Monitorer les privilèges d’accèsIl 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 externesCertaines 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 internationalesL’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é.3
8
Audit jBase et contrôle d’accès
Accès T24L’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 / JBASEActuellement 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.
Accès T24L’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 / JBASEActuellement 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.
39
Audit jBase et contrôle d’accès
40
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
41
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.CUSTOMERex: FBNK.CUSTOMER>SHORT.NAME,FBNK.ACCOUNT>CURRENCYPeut ê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 virguleex: 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 virguleex: FBNK.STMT.ENTRY,FBNK.CATEG.ENTRYUtilisé lors qu’il est précisé ALL dans le champ 1.
Field 4 – commandes d’exception, séparé par une virguleex: LIST,SELECT,SORTUtilisé lors qu’il est précisé ALL dans le champ 2
Configuration du contrôle d’accès F.TAFC.ACCESS.PARAM – SYSTEM
t24oper ----- Identifiant Unix
001 FBNK.CUSTOMER>SHORT.NAME,FBNK.ACCOUNT>CURRENCY
002 LIST,JED
003
004
t24admin
001 FBNK.ACCOUNT
002 All
003
004 SELECT,JED
t24support
001 All
002
003 FBNK.STMT.ENTRY,FBNK.CATEG.ENTRY
004
Exemple de TAFC.ACCESS.PARAM
• 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
Journal d'audit - F.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
001 jsh.b -> jsh.b -> jsh.b
002 jutil_jsh__dev_pts_99
003 09 MAR 2012 12:08:36
004 LIST FBNK.ACCOUNT
005 t24oper
006 192.168.56.101
007 t24prodserver
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
Exemple TAFC.AUDIT.LOG
SUBSETTING
46
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
Archivage – Notre approche
47
Happy Client
Configurer la table de paramètres et trail run
Scoping
Support post Live
Corriger relance de archivage /
récupération / scrambling
Déploiement en
production et Formation
Stratégie d'archivage et stockage
des données
COB validé/ online
Tests UAT avec
validation de l'utilisateur business
Méthodologie
Nous contacterITSS
109, rue du Pont du Centenaire
CH – 1228 Plan-les-OuatesSuisse
Tel: + 41 22 706 20 80www.itssglobal.com
Nous contacterITSS
109, rue du Pont du Centenaire
CH – 1228 Plan-les-OuatesSuisse
Tel: + 41 22 706 20 80www.itssglobal.com
Merci pour votre attention!
QUALITY PARTNER FOR YOUR EXPANSION