Dynamic Enforcement of Security Policies in Multi-Tenant Cloud Networks

Au cours des dernières années, l'évolution des nouvelles technologies a été drastique. Désormais, les ordinateurs et les réseaux ont une place cruciale, que ce soit pour les individus, les grandes entreprises ou les gouvernements. Internet est devenu une partie importante de nos vies personnelle et professionnelle, et est devenu une infrastructure critique au même titre que les réseaux électriques, tant la quantité de données numériques et devenue importante. Cette évolution continue avec la montée en puissance de l'informatique en nuage. Dans ce nouveau modèle, on peut accéder à distance à des logiciels, à du stockage numérique ou bien à des infrastructures. Les machines sont regroupées en centre de données dont l'accès se fait de manière transparente par internet. La sécurité de l'information est devenue primordiale en informatique, et également dans l'informatique en nuage. En effet, les entreprises exportant leurs données désirent obtenir le même niveau de sécurité que sur leurs propres installations, tant leurs données peuvent être sensibles. Nous appellerons middlebox, un élément du réseau autre qu'un routeur ou commutateur, ayant pour fonction d'inspecter et de filtrer les paquets, dans un but autre que la retransmission de paquet. Un pare-feu est un bon exemple de middlebox. Les solutions existantes pour sécuriser l'informatique en nuage prennent rarement en considération la traversée de chaînes de sécurité consistant en l'application successive de middlebox de sécurité. En effet, les solutions courantes se concentrent plus sur l'isolation des trafics entre les différents clients du centre de données. De plus, les solutions prenant en compte l'application de middlebox le font d'une façon qui empêche, ou tout du moins qui contraint la migration des nœuds au sein du réseau. Notre projet consiste en la création d'une architecture permettant l'application de politiques de sécurité par client, au sein d'un centre de données en nuage. Les politiques de sécurité seront des séquences de middlebox que le trafic des clients devra traverser. En effet, c'est de cette façon que la sécurité est assurée dans les entreprises. L'application de ces politiques de sécurité devra prendre en compte la migration des machines au sein du réseau. Plus précisément, le trafic devra traverser uniquement la séquence de middlebox requise par le client, pas une de plus, pas une de moins. L'application des politiques doit être automatiquement reconfigurée lors de la migration des machines virtuelles. Afin de réaliser ce projet, nous utilisons une architecture de réseau programmable afin d'atteindre nos objectifs. Dans cette architecture, le plan de contrôle est découplé du plan de données ce qui permet de centraliser la gestion du réseau. Les clients de notre architecture définissent le niveau de sécurité qu'ils veulent voir être appliqué à leur machines. Nous utilisons un identifiant d'application, AppID), afin de désigner une politique de sécurité en particulier. Nous supposons que l'hyperviseur a la capacité d'insérer cet AppID au sein des paquets, lorsqu'une machine en émet. Au moment où le premier paquet d'un flux atteint un commutateur du réseau, il est transférer au contrôleur de réseau, qui a pour tâche de lire cet AppID. En fonction de ce dernier, le contrôleur détermine la chaine de sécurité à appliquer au trafic. Nous définissons différents marqueurs (que nous nommons EEL-tags) afin d'effectuer le routage des paquets au sein du réseau. Ceux-ci sont subdivisés en gTag et iTag. Les gTags correspondent à des types de middlebox, tandis que les iTags correspondent à des instances de middlebox. Ainsi, une chaîne de sécurité est définie par des gTag. On s'en sert afin de déterminer quels types d'instances seront traversés, tandis que les iTags correspondants sont utilisés afin d'effectuer le routage des paquets au sein du réseau, en définissant la prochaine instance à traverser. Le contrôleur conserve une base de données liant les instances de middlebox ainsi que leurs tags correspondants. En ajoutant ces EEL-tags aux paquets, notre modèle procure une façon simple et automatique d'appliquer des politiques de sécurité, tout en s'assurant de leur cohérence malgré la migration des nœuds. De plus, notre modèle permet au réseau d'être divisé en petites zones, chacune d'entre elle étant contrôlée par un contrôleur de réseau spécifique. Lorsque les machines émettrice et réceptrice se trouvent dans deux zones différentes, l'application de la politique de sécurité peut être divisée entre les différentes zones. Nous avons développé un prototype que nous avons testé dans un environnement simulé. Bien que de nombreux aspects de notre implémentation requièrent de l'amélioration afin d'obtenir une solution commerciale, cette expérimentation nous a permis d'obtenir une preuve de concept de notre architecture. Nous avons notamment pu observer que les politiques de sécurité restent cohérentes malgré la migration de nœuds.