L’objectif principal de cette thèse est de résoudre des problèmes infonuagiques, tels que les risques et les défis de sécurité dans le contexte du SaaS. Dans ce chapitre, nous présentons les démarches qui nous permettent d’atteindre nos objectifs de recherche présentés dans le chapitre d’introduction.
3.1 Premier objectif de recherche
Le premier objectif de notre recherche est la conception d’un cadre infonuagique pour per- mettre aux fournisseurs SaaS d’intégrer des contremesures de SQLIA. Ce cadre est détaillé dans l’article du quatrième chapitre qui s’intitule « SQLIIDaaS : A SQL injection intrusion detection framework as a service for SaaS providers ». Afin de détecter les SQLIAs visant un SaaS sans accéder à son code source, nous proposons d’extraire les requêtes HTTP et SQL à partir des paquets. Ensuite, chaque SQL est associée à la HTTP correspondante grâce à un algorithme de corrélation qui se base sur la similarité entre les littéraux des requêtes SQL et les paramètres des requêtes HTTP. Ce cadre est développé sous forme des images de VMs, ce qui permet de respecter les caractéristiques d’un service de sécurité telles que : libre-service, élasticité des ressources, mutualisation des ressources et paiement à l’usage.
Ce cadre permet de détecter les attaques par injection SQL qui consistent à modifier la syntaxe des requêtes SQL au moment de l’exécution dans le contexte d’une base de données relationnelle. Par exemple, il ne détecte pas les injections SQL à l’aveugle qui consistent à deviner des informations en se basant sur des valeurs booléennes (vrai ou faux) retournées par une requête SQL ou son temps d’exécution. Il permet d’intégrer des contremesures des injections SQL qui se basent sur l’analyse dynamique des requêtes HTTP et/ou SQL.
Bien que ce cadre permette d’intégrer les différents types des contremesures de SQLIA avec une haute portabilité par rapport aux langages de programmation, il présente certaines fai- blesses énumérées comme suit :
— Il ne supporte que le modèle de données qui consiste à créer une base de données pour chaque locataire d’un SaaS.
— Il exige l’acheminement des requêtes HTTP et SQL vers une NAT VM (NATVM for Network Address Translation Virtual Machine), qui représentera un point de dé- faillance unique.
— Il est incompatible avec le protocole HTTPS, car il ne peut pas extraire les détails des requêtes HTTP qui sont encryptées sur la NATVM.
Nous avons remédié à ces faiblesses dans notre troisième objectif de recherche.
3.2 Deuxième objectif de recherche
Le deuxième objectif de notre recherche est la conception d’un cadre infonuagique pour dé- tecter et prévenir les attaques entre les locataires d’un SaaS qui partagent certaines tables d’une base de données relationnelle. Ce cadre est détaillé dans l’article du cinquième cha- pitre qui s’intitule « ITADP : an inter-tenant attack detection and prevention framework for multi-tenant SaaS ». Dans cet article, nous définissons une grammaire SQL pour une base de données multi-locataire. Cette grammaire est employée pour vérifier si une requête SQL, exécutée à partir du domaine d’un locataire (www.tenant1.SaaSApp.com), manipule les enre- gistrements d’autres locataires (tenant2, tenant3, etc.) sans la nécessité d’accéder aux tables partagées de données. Certains algorithmes ont été proposés pour analyser l’arbre syntaxique d’une requête SQL (au moment de l’exécution) dans le but de vérifier sa conformité vis-à-vis de certaines règles. La violation de ces règles est considérée comme une potentielle attaque entre les locataires. Les algorithmes proposés sont optimisés afin de réduire le temps de la détection des attaques entre locataires.
3.3 Troisième objectif de recherche
Le troisième objectif de notre recherche est la conception d’un cadre infonuagique pour inté- grer plusieurs IDS applicatives tout en assurant les caractéristiques d’un service de sécurité pour les fournisseurs et locataires d’un SaaS. Ce cadre est détaillé dans l’article du sixième chapitre qui s’intitule « Multi-tenant intrusion detection framework as a service for SaaS ». Dans cet article, nous avons pallié aux lacunes du cadre conçu durant la réalisation du premier objectif comme suit :
— L’analyse des requêtes SQL a été adaptée aux deux autres modèles de données (schéma- par-tenant et tables-partagées).
— Les requêtes HTTP et SQL sont interceptées et corrélées sur la VM qui contient les services Web. Cela rend le cadre compatible avec le protocole HTTPS, tout en évitant d’avoir NATVM comme un point de défaillance unique. Cette amélioration permet aussi d’assurer une haute disponibilité et de réduire l’impact sur le temps de réponse aux requêtes HTTP, puisqu’il n’est plus nécessaire d’acheminer les requêtes vers NATVM.
— Une élasticité des ressources est assurée en diminuant et augmentant (automatique- ment) le nombre des VMs en fonction de l’utilisation du processeur. Cela permet aussi de réduire le coût global du cadre.
— Un paiement à l’usage est assuré grâce à la proposition d’un modèle mathématique de coût fournisseur.
Afin d’offrir ce cadre en tant que service de sécurité multi-locataire, les requêtes HTTP et SQL sont regroupées par locataire (en temps réel). Ensuite, chaque locataire peut spécifier et modifier ses exigences de sécurité, par exemple, pour se protéger contre certaines attaques en libre-service. Il paie aussi à l’usage grâce à la proposition d’un modèle mathématique de coût locataire qui prend en considération la quantité du trafic et les exigences de sécurité de chaque locataire.
3.4 Conclusion
Dans ce chapitre, nous avons présenté notre démarche scientifique qui trace le cheminement choisi pour atteindre l’objectif principale de cette thèse. Les trois chapitres suivants détaillent les trois articles scientifiques qui nous permettent d’étayer la réalisation de nos trois objectifs de recherche.
CHAPITRE 4 ARTICLE 1 : SQLIIDaaS : A SQL INJECTION INTRUSION