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.

Abstract

During the past decades, the evolution of technology has drastically changed our ways. All major enterprises, government services, and even us as individuals, rely on computers and networks. They have become a part of our personal and professional lives and represent nowadays a critical infrastructure as the amount of data stored numerically as well as its sensitivity has grown considerably. This evolution continues with the rise of cloud computing. In this new model, one can access software, digital storage or infrastructure without constraints, as the hardware is pooled in remote data center, accessed seamlessly via Internet. Security has become a major concern in computer science in general and in the cloud in particular, as enterprises moving to the cloud would have to export some of their sensitive data. Therefore, the cloud providers need to offer a level of security which matches what the companies have in their on-site installations. A middlebox is a network appliance that inspects and filters packets for purposes other than packet forwarding. A firewall is a good example of a middlebox. Existing solutions to secure the cloud rarely take in consideration the traversal of middleboxes, as they focus mainly on creating isolation between the different tenants. Furthermore, the solutions considering the traversal of middlebox sequences do so in a way which does not permit the migration of nodes. Through our project, we aim to create a cloud architecture allowing the application of security policies per tenant. The security will consist in sequences of middleboxes to be traversed, as it is the way commonly used by enterprises to secure their networks. The enforcement of security policies will have to take in consideration the multi-tenant aspect of the cloud, as well as the node migration. Particularly, traffic should traverse middleboxes in the sequence required by the tenant and should not traverse unnecessary middleboxes. The enforcement of policies should be automatically re-configured due to VM migrations. In this work, we propose a method of leveraging the current Software-Defined Network (SDN) architecture for efficient policy enforcement. SDN is a form of network architecture in which the control plane is separated from the data plane, allowing the network to be centrally managed. Therefore, the tenants define the security design they want to apply to their Virtual Machine (VM), or groups of VMs. In order to identify the security policies, we use an Application ID (AppID), which actually refers to a chain of middleboxes to be traversed. We assume that the running hypervisor has the capability to add this AppID into the flow when a VM emits packets. When the first packet of a flow reaches a switch, it is forwarded to the network controller, which in turn retrieves the AppID from the packet. Based on the AppID, the controller determines the chain of middleboxes to be traversed. In order to route the packets through the middleboxes, our model defines labels to apply to each flow of packets (EEL-tags). The latter are divided in generic EEL-tag (gTag) and instance EEL-tag (iTag). Each gTag corresponds to a middlebox type, and each iTag corresponds to a middlebox instance. The security chain is defined by a chain of gTags. The iTags are added to the packets in order to route the packets across the network, defining the next middlebox the packet must be sent to. By using the EEL-tags, this model provides a simple way to automatically enforce security policies, while keeping them consistent despite node migration. Furthermore, we allow the network to be partitioned in different zones, each zone being ruled by a specific controller. When the VM source and destination belong to different zones, the enforcement of security policies can be spread between the different zones. We created a prototype of our model that we tested in a simulated environment. Although many aspects of our implementation will have to be improved in order to obtain a viable commercial solution, testing our prototype provided us with a proof of concept. Particularly, it showed how the security policies remain consistent despite node migration.