L’informatique en nuage est un type d’environnement hétérogène et dynamique de plus en plus utilisé. Différents modèles de service et de déploiement existent et permettent de répondre à des besoins variés des utilisateurs. La combinaison d’un environnement hétérogène et des nombreuses applications utilisateurs fait de la sécurité un point essentiel mais complexe à adresser. La définition des besoins de sécurité peut en effet être une tâche difficile, d’autant plus que l’utilisateur du service ne connait pas nécessairement ces besoins. Cependant, nous avons vu qu’il existe des méthodes d’analyse des risques qui permettent à un utilisateur de déterminer ses besoins de sécurité. Ainsi, dans la suite de ce document, nous considèrerons que l’utilisateur du service est capable d’établir la liste de ses besoins, si nécessaire en utilisant l’une de ces méthodes.
Lorsque l’utilisateur du service a déterminé ses besoins de sécurité, un langage doit permettre d’exprimer ces besoins. Nous avons donc vu quelles sont les différentes proprié-tés de sécurité fondamentales qui peuvent correspondre aux besoins d’un utilisateur, ainsi que plusieurs modèles de politiques permettant d’exprimer ces besoins. Cependant, aucun langage ne permet actuellement d’exprimer une politique de sécurité qui soit indépendante des mécanismes sous-jacents et du système (puisqu’il s’agit d’un environnement hétéro-gène), qui couvre l’ensemble des couches d’une infrastructure en nuage et qui permette d’exprimer à la fois les besoins d’application de la sécurité et les besoins d’assurance.
Dans les chapitres qui suivent, nous proposons donc un langage répondant à ces diffé-rents manques, associé à une architecture capable d’interpréter ce langage. Ainsi, le langage proposé devra permettre de définir une politique de sécurité et d’assurance qui soit adap-tée aux environnements en nuage : cette politique devra donc être aussi indépendante que possible du système et des mécanismes sous-jacents. L’architecture devra quant à elle être capable d’appliquer cette politique en configurant les mécanismes de sécurité présents. En effet, l’objectif de l’architecture n’est pas de proposer un nouveau mécanisme de sécurité, mais de réutiliser les fonctionnalités des nombreux mécanismes existants pour couvrir un large panel de besoins. De plus, l’architecture devra être capable de s’adapter aux méca-nismes disponibles pour la projection des propriétés et de reconfigurer les mécaméca-nismes en cas de défaillance de l’un d’entre eux.
Chapitre 3
Langage
L’informatique en nuage est de plus en plus utilisée, à la fois par les particuliers et par les entreprises. Ces dernières l’utilisent dans plusieurs buts, par exemple pour stocker des données ou pour externaliser une partie de l’architecture logicielle de l’entreprise. Dans ce cas, l’administrateur de l’architecture logicielle doit pouvoir exprimer ses besoins de sé-curité, c’est-à-dire définir quelles sont les ressources à protéger et quelles sont les actions autorisées ou interdites sur ces ressources. Un besoin de sécurité peut par exemple être la nécessité de garantir la confidentialité d’un fichier, autrement dit de contrôler quels utili-sateurs peuvent accéder à l’information de ce fichier, ou la confidentialité d’une connexion entre deux services distants, c’est-à-dire s’assurer que l’information échangée entre ces deux services ne peut pas être lue par une entité tierce.
L’une des caractéristiques de l’informatique en nuage est l’hétérogénéité à la fois des systèmes d’exploitation utilisés, mais aussi des services ou applications déployés. L’expres-sion des besoins de sécurité est donc complexe et doit être adressée par un langage adapté à de tels systèmes.
L’informatique en nuage est également caractérisée par son aspect dynamique, puisque des machines virtuelles peuvent être déployées, migrées ou arrêtées à tout moment. Ce-pendant, les besoins de sécurité d’une machine virtuelle donnée évoluent peu au cours de la vie de cette machine. En effet, les machines virtuelles sont généralement dédiées à un service (par exemple, une plateforme de création de sites Web ou un serveur de partage de données). De plus, si un nouveau service doit être mis en place, la création d’une nouvelle machine virtuelle sera préférée à la modification d’une machine existante (par exemple, la modification d’une machine virtuelle servant de serveur Web en serveur de partage de fichier). Ainsi, nous choisissons de ne pas prendre en compte ce côté dynamique du nuage informatique lors de l’expression des besoins de sécurité.
L’environnement étant hétérogène, les ressources à protéger et les mécanismes utilisés diffèrent selon les systèmes. Or, il n’existe pas actuellement de langage adapté aux environ-nements en nuage et permettant d’exprimer des besoins de sécurité (section 2.1). L’objectif de ce chapitre est donc de définir un langage permettant d’abstraire ces éléments afin d’ob-tenir une politique indépendante du système et des mécanismes. Cela permet alors à une même politique d’être portable et donc d’être appliquée sur plusieurs systèmes.
L’informatique en nuage étant un environnement en constante évolution, il est indispen-sable que le langage soit extensible. En effet, il doit permettre de répondre à de nouveaux besoins de sécurité, par exemple des besoins spécifiques à un cas d’usage précis.
Dans le langage défini dans ce chapitre, les besoins de sécurité sont exprimés en utilisant des propriétés. Le langage doit donc être générique, afin qu’une même propriété puisse être appliquée et assurée différemment selon les ressources mises en jeu. De plus, le langage doit
être simple et offrir à l’utilisateur la possibilité de définir facilement ses besoins. Finalement, le langage doit permettre d’adresser un maximum de besoins de sécurité.
Dans ce chapitre, nous verrons tout d’abord quelles doivent être les caractéristiques d’un langage d’expression des besoins de sécurité pour l’informatique en nuage (section 3.1). Puis, nous donnerons une vue globale des différents éléments du langage et de leurs inter-actions (section 3.2). Les sections 3.3, 3.4 et 3.5 détailleront les éléments du langage, ce qui permettra de définir une politique de sécurité (section 3.6). Enfin, la section 3.7 conclura ce chapitre.
3.1 Caractéristiques du langage
Un langage d’expression des besoins de sécurité pouvant être utilisé dans un environne-ment hétérogène et dynamique doit posséder des caractéristiques spécifiques. Cette section détaille les besoins auxquels notre langage doit répondre.
En premier lieu, un environnement hétérogène implique que les différents nœuds peuvent utiliser des systèmes d’exploitation différents. Par conséquent, les ressources peuvent suivre des conventions de nommage différentes et les mécanismes de sécurité ne sont pas néces-sairement les mêmes. Il est donc nécessaire que le langage puisse s’abstraire de ces deux éléments.
Sur un système, les ressources sont associées à un identifiant (leur nom ou leur chemin). Cet identifiant dépendant du système sur lequel la politique est déployée, il ne peut pas être utilisé pour identifier les ressources dans notre langage. En conséquence, le langage utilise la notion de contextes afin de s’abstraire du système de nommage des ressources systèmes (section 3.3), ce qui permet au langage d’être indépendant des ressources.
De plus, les mécanismes de sécurité utilisés pour répondre aux besoins de sécurité ne sont pas identiques selon les systèmes ou les couches du système. C’est pourquoi un langage d’expression des besoins de sécurité pour un environnement hétérogène doit être indépen-dant des mécanismes. Le langage doit donc abstraire les mécanismes de sécurité et leurs fonctionnalités en utilisant des capacités (section 3.4). Il sera ainsi possible d’exprimer des besoins sans préciser quels mécanismes y répondront. Grâce à cette indépendance des mé-canismes, le langage peut également être adaptatif : il peut s’adapter aux mécanismes présents pour offrir la meilleure protection possible.
Afin de couvrir un large panel de besoins de sécurité, le langage doit également être extensible, c’est-à-dire qu’il doit offrir la possibilité de définir de nouvelles propriétés. En effet, bien qu’il soit nécessaire que le langage propose des propriétés générales prédéfi-nies permettant de protéger un système ou des applications usuelles, de nouveaux besoins peuvent émerger dans un cas d’usage spécifique. Il doit donc être possible de définir et d’ajouter des propriétés répondant à ces nouveaux besoins (section 3.5). De plus, le lan-gage doit également permettre d’intégrer facilement de nouveaux mécanismes de sécurité en réutilisant des capacités existantes, mais également d’ajouter de nouvelles capacités, c’est-à-dire de nouvelles fonctionnalités de mécanismes.
En outre, le langage doit être générique : les propriétés de sécurité doivent être ca-pables de s’adapter aux ressources concernées. Par exemple, une propriété de confidentialité doit pouvoir être appliquée et assurée à la fois sur des ressources systèmes et sur des res-sources réseaux, en utilisant respectivement des mécanismes systèmes et réseaux. Ainsi, une même propriété doit pouvoir, selon la nature des ressources, être mise en œuvre de différentes manières, en utilisant des mécanismes appropriés et disponibles (section 3.5.3). Enfin, le langage doit être simple d’utilisation. En effet, dans le cas de l’informatique en nuage, le client définissant la politique (que nous nommerons par la suite l’administrateur