280 likes | 643 Views
2012-04-11. 2. ?quipe. USherbrookeMarc Frappier, Richard St-DenisParis-12Fr?d?ric Gervais, R?gine LaleauFinanci?re Banque NationaleLouise Adant, Aicha Chafaqi, Jean-Fran?ois Desch?nes, Mario Richard3 PhD 4 MScPhD : M. E. Jiague, P. Konopacki, J. MilhauMsC : A. Beaupr?, R. Chossart, A.L.K.
E N D
1. 2012-04-11 1 Sécurité fonctionnelle dans les applications bancaires Marc Frappier, Ph.D.
professeur
GRIL – Groupe de recherche en ingénierie du logiciel
2. 2012-04-11 2 Équipe USherbrooke
Marc Frappier, Richard St-Denis
Paris-12
Frédéric Gervais, Régine Laleau
Financière Banque Nationale
Louise Adant, Aicha Chafaqi, Jean-François Deschênes, Mario Richard
3 PhD + 4 MSc
PhD : M. E. Jiague, P. Konopacki, J. Milhau
MsC : A. Beaupré, R. Chossart, A.L.K. Djiffouet
3. 2012-04-11 3 Financement CRSNG
Programme stratégique
200 K $
2 ans
4. 2012-04-11 4 Objectifs du projet Spécification abstraite des politiques de sécurité fonctionnelle d’un système d’information (SI)
Génération automatique d’un noyau de sécurité mettant en œuvre les politiques de sécurité fonctionnelle d’un SI
5. 2012-04-11 5 Sécurité fonctionnelle propriétés de sécurité relatives aux fonctions (services) d’un système d’information
3 niveau de granularité
données : objets et attributs
services
processus d’affaires
6. 2012-04-11 6 Exemples de propriétés de sécurité fonctionnelle Un courtier d’une banque doit obtenir l’autorisation de son superviseur si le montant d’une transaction > 100 K$
Un courtier peut effectuer des opérations pour un client après que celui-ci lui ait donné son autorisation
Un superviseur ne peut autoriser ses propres transactions
Le personnel de l’urgence peut avoir accès de manière temporaire au dossier partiel d’un patient; les accès sont documentés dans une trace accessible par le patient.
7. 2012-04-11 7 Sécurité architecturale/technique Out of scope!
Composantes architecturales d’une implémentation d’un système sécurisé
authentification
cryptage
protocole de communication sécurisé
etc.
8. 2012-04-11 8 Contexte Dans la plupart des SI, les propriétés de sécurité fonctionnelle sont imbriquées avec les spécification des fonctions
spec
code
Le code source constitue la seule description précise et à jour des propriétés
La maintenance des propriétés est complexe
Les règles de sécurité sont
statiques, paramétrées
9. 2012-04-11 9 Contexte Règlementations se resserrent de plus en plus
USA
Sarbane-Oxley (Gestion d’entreprise)
HIPAAA (santé)
Canada
AMF (Québec) : règlement 52-109 et 52-111
PIPEDA : Personal Information Protection and Electronic Documents Act
10. 2012-04-11 10 Contexte Besoin de mettre à jour rapidement les politiques de sécurité
Société générale : 5 G$ de perte en transactions non autorisées
Difficile
politiques sont enfouies dans le code source
mal documentées
11. 2012-04-11 11 Contexte Système d’information
c’est plus qu’une BD ...
complexité règles d’affaires (> 200 000 dans une banque)
de plus en plus complexe au niveau technologique
distribués
accessibles par internet
multi-plateformes
hétérogènes
critiques pour le bon fonctionnement d’une entreprise
12. 2012-04-11 12 Objectifs Permettre modification dynamique des politiques de sécurité
en temps réel
pas besoin de recompiler le SI
Spécification des politiques basée sur spécification du SI
modèle de données
signature des services
13. 2012-04-11 13 Contexte technologique SOA
architecture services
multi niveaux (multi-tiers)
Données hétérogènes
Oracle
IMS
XML
14. 2012-04-11 14 Contexte technologique
15. 2012-04-11 15 Contexte FBN – niveau données et service Règles
statiques : encodées dans un programme générique qui gère les menus et procédures stockées
paramétrées : par des tables qui déterminent les accès aux données et fonctions
temporelles (quelques-unes) : validité dans le temps
Cohérence entre accès données et accès fonctions
ex: détecter qu’un usager à droit à une fonction, mais pas aux données manipulées par cette fonction
16. 2012-04-11 16 Contexte FBN – niveau processus d’affaires Politiques de sécurité
encodées dans les programmes d’application
pas de séparation avec la logique d’affaires
Niveau données et services est un premier filtre
17. 2012-04-11 17 Travaux connexes Niveau 1 et 2 (données et services)
Bell et Lapadula (1973), Biba (1977)
contrôle de l’accès et classification
Clark and Wilson (1987)
autorisation et maintient de l’intégrité
*RBAC = RBAC (1996), ORBAC (2003), GTRBAC (2005), WS-RBAC (2004)
fondés sur notion de rôle
Rien pour le niveau 3 (processus)
18. 2012-04-11 18 Méthodologie Approche formelle et MDE-MDA
Langage de spécification pour les 3 niveaux
Inspiré de
*RBAC : rendre plus polyvalents et génériques
Algèbre de processus EB3
ASTD : Algebraic State-Transition Diagrams
Théorie du contrôle
Traduction vers une plateforme particulière
19. 2012-04-11 19 MDE-MDA MDE = Model-Driven Engineering
MDA = Model-Driven Architecture
CIM = Computation Independent model
PIM = Platform Independent Model
PSM = Platform Specific Model
20. 2012-04-11 20 Processus gestion sécurité
21. 2012-04-11 21 PIM Modèle de l’application
modèle de données (E-R)
signature des services
[ spécification fonctionnelle des services]
liens entre services et données
indépendant du modèle de sécurité
Modèle de sécurité
données, services, processus
organisation, rôles, etc
accès en lecture au modèle de l’application
22. 2012-04-11 22 Validation PIM Cohérence politique
Propriétés conflictuelles
ex: X a accès au service Y, mais pas aux données du service Y
ex: X doit faire approuver par Y, mais Y n’a pas accès au service d’approbation
Vérification automatique
model checking (exhaustif, aléatoire, échantillonage)
Preuve
23. 2012-04-11 23 Règles de transformationPIM vers PSM génération de code
politique exprimée sous forme de prédicat
exécution symbolique
sémantique opérationnelle de EB3 et ASTD
architecture distribuée
24. 2012-04-11 24 Algebraic State-Transition Diagrams
25. 2012-04-11 25 Études de cas FBN Point de départ pour la définition de EB3SEC
Identification des caractéristiques du langage nécessaires pour la spécification des politiques de sécurité des cas d’études
26. 2012-04-11 26 Conclusion EB3sec innove en intégrant les 3 niveaux de granularité de la sécurité
données, service, processus
Politiques validées et exécutables
model checking, preuve, règles de transformation
Prototype pour l’environnement de la Financière Banque Nationale
architecture web service distribuées