Besoins de sécurité - Description du cas d’usage

6.1 Description du cas d’usage

6.2.1 Besoins de sécurité

Les besoins de sécurité sont exprimés par l’administrateur de l’architecture logicielle en se basant sur la figure 6.2. Cinq besoins de sécurité généraux sont établis :

1. Isoler les services et applications systèmes : Apache, ApacheGUI, phpMyAdmin, MySQL, nginx ;

2. Isoler les services et applications réseaux : seuls les ports de ces services doivent être atteignables ;

3. Isoler les VM ;

4. Fournir un accès à la paire Apache/MySQL au client correspondant. 5. Donner à chaque utilisateur des droits spécifiques :

– CloudProvider peut administrer les hôtes physiques et OpenStack ;

– TenantOperator peut administrer les VM (installer les paquets, vérifier les logs systèmes), mais pas les applications administrées par TenantAdmin ;

– TenantAdmin peut administrer les services fournis à l’utilisateur (Apache, php-MyAdmin, MySQL), modifier leur configuration, lire leurs logs et les redémarrer ; – User peut utiliser les trois applications (ApacheGUI, phpMyAdmin, MySQL). La définition de ces besoins peut résulter de l’utilisation d’une méthode d’évaluation des risques et permet la définition de la politique.

6.2. POLITIQUE DE SÉCURITÉ 6.2.2 Politique de sécurité

Dans cette section, nous détaillons les politiques de sécurité qui découlent des besoins et qui sont utilisées pour protéger l’architecture logicielle du cas d’usage. La figure 6.3 synthétise cette architecture logicielle. Seul un triplet de VM Client-Apache-MySQL est représenté : les politiques sur les autres VM sont identiques (à l’exception des associations de contextes aux ressources qui peuvent diﬀérer selon la distribution choisie).

Figure 6.3 – Description du cas d’usage

La figure présente donc les quatre machines virtuelles du cas d’usage. La VM Apache est le serveur Web et exécute trois applications : Apache et PHPMyAdmin (domaine Web), et ApacheGUI (domaine WebApps). La VM MySQL héberge la base de données associée au serveur Web. Ces deux VM sont reliées sur le réseau interne à la VM proxy (Nginx).

Les propriétés à exprimer, et répondant aux besoins, sont les suivantes :

1. Chacune des applications est isolée dans un domaine (cadre orange) et les interactions à l’intérieur de ce domaine font partie de la propriété d’isolation. Les opérations de lecture et d’écriture (flèches bleues, rouges et violettes) vers les domaines sont préci-sées : les utilisateurs TenantOperator et TenantAdmin n’ont donc pas les mêmes autorisations d’interactions avec les ressources de ces applications. De plus, les exé-cutions de fichiers sont spécifiées (flèches vertes) pour chacun des fichiers exécutables (autorisées pour TenantAdmin).

d’ouverture de ports réseaux pour les VM sources spécifiées.

3. Ces VM sont déployées sur les nœuds de calcul OpenStack. Elles peuvent être sur une seule machine physique ou sur des machines diﬀérentes. Les nœuds de calculs ont tous la même politique de sécurité, qui autorise la connexion SSH du fournisseur de l’infrastructure (nécessitant ainsi l’ouverture du port SSH). De plus, chaque nœud de calcul est chargé d’isoler les diﬀérentes VM qu’il héberge (cadre orange).

4. La propriété permettant les connexions d’un client aux VM Apache et MySQL est également décrite sur le schéma.

5. Les authentifications locales autorisées (c’est-à-dire les utilisateurs autorisés à se connecter en utilisant des services) sont également visibles sur le schéma (flèches pointillées).

La figure 6.4 présente les propriétés d’authentifications distantes de la politique (flèches pointillées). Pour chaque flèche représentant une propriété d’authentification, les utilisa-teurs de la machine source peuvent se connecter sur un service (nœud intermédiaire) avec le nom d’utilisateur cible (fin de la flèche).

Figure 6.4 – Description du cas d’usage

Le reste de cette section présente un extrait des définitions des contextes, de leur asso-ciation aux ressources et des propriétés à appliquer. La politique complète de ce cas d’usage est disponible à l’annexe B.

6.2.3 Contextes

En se basant sur l’architecture logicielle et sur les besoins de sécurité définis par l’admi-nistrateur de l’architecture logicielle, nous pouvons définir l’ensemble des contextes mis en jeu dans les propriétés. Nous pouvons également définir les associations entre les contextes et les ressources réelles, associations qui dépendent des systèmes déployés.

6.2. POLITIQUE DE SÉCURITÉ 6.2.3.1 Définition

La politique de sécurité définit tout d’abord les contextes qui seront mis en jeu dans les propriétés. Cette section présente les contextes pour les politiques des diﬀérentes ma-chines. Tous ne sont pas utilisés sur chacune des machines, mais la majorité intervient dans plusieurs politiques.

Le listing 6.1 présente les contextes associés aux machines impliquées dans ce cas d’usage. Le premier contexte identifie les machines physiques, c’est-à-dire les nœuds de calcul OpenStack. Les contextes suivants (lignes 2 à 5) identifient chacune des VM, le contexte suivant (ligne 6) identifie l’ensemble de ces VM, et les deux derniers contextes identifient toutes les machines.

1 HOST = (Hardware.Computer = "nova-compute-node");

2 HostReverseProxy = (Hardware.Computer.VM = "reverse-proxy-nginx");

3 HostClient = (Hardware.Computer.VM = "client");

4 HostServerWEB = (Hardware.Computer.VM = "apache-see");

5 HostServerSQL = (Hardware.Computer.VM = "mysql-see");

6 VMs = (Hardware.Computer.VM = ".*");

7 anyone = (Hardware.Computer = ".*");

8 anyIP = (Network.IP = ".*");

Listing 6.1 – Contextes des machines

Le listing 6.2 définit les contextes des utilisateurs intervenant dans le cas d’usage ainsi que leurs rôles. Les rôles possibles sont StandardUser (pas d’autorisation spé-cifique), PackageAdmin (installation de paquets), SysnetAdmin (gestion du réseau), LoggingAdmin(accès aux logs systèmes) et WEBAdmin (administration des applications Web). Les deux premiers utilisateurs ont un rôle d’administrateur système, CloudProvider pour les machines hôtes et TenantOperator pour les VM. TenantAdmin administre les applications Web exécutées sur les VM et User les utilise. Les propriétés spécifiques aux rôles systèmes ne seront pas détaillées, puisque seule la partie de la politique liée au cas d’usage est donnée.

1 CloudProvider = (Identity.Username="idCloudProvider"):(Identity.Role=" StandardUser|PackageAdmin|SysnetAdmin"); 2 TenantOperator = (Identity.Username="idTenantOperator"):(Identity.Role=" StandardUser|PackageAdmin|SysnetAdmin"); 3 TenantAdmin = (Identity.Username="idTenantAdmin"):(Identity.Role=" StandardUser|LoggingAdmin|WEBAdmin"); 4 User = (Identity.Username="idUser"):(Identity.Role="StandardUser");

Listing 6.2 – Contextes des utilisateurs

Le listing 6.3 contient les contextes associés aux ressources des applications fournies. Les lignes 2 à 4 définissent trois domaines qui correspondent aux diﬀérentes applications présentes. DomainWEB identifie à la fois nginx (sur la VM proxy), et Apache et PHP-MyAdmin (sur la VM Apache). DomainWEBAPPS identifie ApacheGUI, et DomainSQL identifie la base de données. Les contextes des lignes 7 à 10 identifient les fichiers du do-maine Web, et les deux groupes de contextes suivants (lignes 12-16 et 18-21) identifient ceux des domaines WebApps et SQL.

1 // Domains 2 DomainWEB = (Domain="App_Web"); 3 DomainWEBAPPS = (Domain="App_Web_Apps"); 4 DomainSQL = (Domain="App_Database"); 5 6 // Resources

7 FileWEB = DomainWEB:(Type.Passive.Data.File="default"); 8 BinaryWEB = DomainWEB:(Type.Passive.Data.File.Binary="bin_exec"); 9 ConfigWEB = DomainWEB:(Type.Passive.Data.File.Configuration="conf"); 10 LogWEB = DomainWEB:(Type.Passive.Data.File.Logs="logs"); 11 12 FileWEBAPPS = DomainWEBAPPS:(Type.Passive.Data.File="default"); 13 BinaryWEBAPPS = DomainWEBAPPS:(Type.Passive.Data.File.Binary="bin_exec"); 14 ConfigWEBAPPS = DomainWEBAPPS:(Type.Passive.Data.File.Configuration="conf"); 15 TmpWEBAPPS = DomainWEBAPPS:(Type.Passive.Data.File.Temporary="tmp"); 16 LogWEBAPPS = DomainWEBAPPS:(Type.Passive.Data.File.Logs="logs"); 17 18 FileSQL = DomainSQL:(Type.Passive.Data.File="default"); 19 BinarySQL = DomainSQL:(Type.Passive.Data.File.Binary="bin_exec"); 20 ConfigSQL = DomainSQL:(Type.Passive.Data.File.Configuration="conf"); 21 LogSQL = DomainSQL:(Type.Passive.Data.File.Logs="logs");

Listing 6.3 – Contextes des domaines et de leurs fichiers

Le listing 6.4 contient les contextes identifiant les services et applications impliqués dans le cas d’usage : SSH et les trois services appartenant aux domaines définis précédemment. 1 ServiceSSH = (Type.Active.Service="SSH"); 2 ServiceWEB = HostServerWEB:DomainWEB:(Type.Active.Service="App_Web"):( Identity.Role="System"); 3 ServiceWEBAPPS = HostServerWEB:DomainWEBAPPS:(Type.Active.Service="App_Web_Apps "):(Identity.Role="System"); 4 ServiceSQL = HostServerSQL:DomainSQL:(Type.Active.Service="App_Database"):( Identity.Role="System");

Listing 6.4 – Contextes des services et applications

Enfin, le listing 6.5 contient les contextes indiquant les ports intervenant dans la poli-tique : ceux des applications (lignes 1 à 3) et celui pour SSH (ligne 4).

1 WEBPort = (Network.Port="80");

2 WEBAPPSPort = (Network.Port="9999");

3 MysqlPort = (Network.Port="3306");

4 SSHPort = (Network.Port="22");

Listing 6.5 – Contextes des ports réseaux

Notons que les contextes définis sont indépendants du système de nommage des res-sources du système. Ces contextes peuvent être fournis à l’ensemble des machines (phy-siques et virtuelles) sans distinction du rôle de la machine (client, proxy, serveur Web, base de données) ou du système utilisé (Fedora, CentOS, ...).

6.2.3.2 Association

Cette section présente l’unique partie de la politique qui est dépendante du système sur lequel la politique doit être appliquée. En eﬀet, elle décrit l’association des contextes abstraits aux ressources réelles et est donc dépendante du système de nommage utilisé et de la localisation des ressources. Étant donné que la même distribution est utilisée sur tous les nœuds serveurs, cette association est identique pour toutes ces machines.

Comme vu à la section 3.3.3, quatre types d’associations sont possibles : u pour les utilisateurs, c pour les adresses IP, o pour les ressources passives et p pour les processus. Le listing 6.6 contient les associations des contextes utilisateurs. La première colonne indique le type d’association dont il s’agit, la deuxième les noms d’utilisateurs Unix et la troisième leur contexte associé. On a ainsi les quatre utilisateurs intervenant dans le cas d’usage.

6.2. POLITIQUE DE SÉCURITÉ

1 u cloudprovider CloudProvider

2 u tenant-admin TenantAdmin

3 u tenant-operator TenantOperator

4 u user User

Listing 6.6 – Association des contextes aux utilisateurs

Dans un second temps, les contextes des machines sont associés à leur adresse IP (voir listing 6.7). Les deux premières lignes donnent les adresses IP de la VM proxy : une seule VM proxy est déployée et ces adresses ne changent donc pas. Les trois lignes suivantes contiennent les adresses d’un groupe de trois VM : elles sont fixées lors du déploiement des VM et donc renseignées dynamiquement dans la politique avant son application. Notons que la VM client a une adresse sur le réseau externe et non le réseau interne, et que la VM proxy a une adresse sur chaque réseau.

1 c 192.168.1.254 HostReverseProxy

2 c 172.30.3.1 HostReverseProxy

3 c 192.168.1.1 HostServerWEB

4 c 192.168.1.101 HostServerSQL

5 c 172.30.3.2 HostClient

Listing 6.7 – Association des contextes aux machines

Le listing 6.8 contient un extrait des associations de contextes aux ressources passives et aux processus sur la VM Apache (les associations relatives au domaine Web). On voit ainsi que les fichiers de ce domaine (lignes 1 à 12) sont relatifs à deux applications : Apache et PHPMyAdmin. Le contexte ServiceWEB est quant à lui associé à un fichier : lorsque ce fichier sera exécuté, le processus résultant aura le contexte associé.

1 o /usr/sbin/httpd BinaryWEB 2 o /usr/lib/httpd(/.*)? BinaryWEB 3 o /etc/httpd(/.*)? ConfigWEB 4 o /var/www(/.*)? FileWEB 5 o /var/www/cgi-bin(/.*)? BinaryWEB 6 o /etc/phpMyAdmin(/.*)? ConfigWEB 7 o /usr/share/phpMyAdmin(/.*)? FileWEB 8 o /var/log/httpd(/.*)? LogWEB 9 o /usr/lib/systemd/system/httpd\.service BinaryWEB 10 o /var/run/httpd(/.*)? FileWEB 11 o /etc/httpd/logs LogWEB 12 o /etc/httpd/modules BinaryWEB 13 14 p /usr/sbin/httpd ServiceWEB

Listing 6.8 – Association des contextes aux objets/processus sur la VM Apache Considérons maintenant l’association de ces mêmes contextes aux ressources de la VM proxy (listing 6.9). Les contextes sont associés aux ressources de l’application Nginx (lignes 1 à 6) et à son processus (ligne 8). L’application à protéger est donc diﬀérente de celles sur la VM Apache, cependant les contextes utilisés sont identiques : les propriétés peuvent donc être les mêmes sur les deux VM (à condition que les besoins de sécurité soient identiques). Les propriétés sont donc bien indépendantes du système de nommage.

1 o /usr/sbin/nginx BinaryWEB

2 o /etc/nginx(/.*)? ConfigWEB

3 o /usr/share/nginx(/.*)? FileWEB

4 o /var/log/nginx(/.*)? LogWEB

6 o /var/run/nginx\.pid FileWEB

8 p /usr/sbin/nginx ServiceWEB

Listing 6.9 – Association des contextes aux objets/processus sur la VM Proxy On voit ainsi que seules les associations de contextes sont dépendantes du système sur lequel la politique doit être appliquée. Cependant, certains éléments peuvent être générés automatiquement selon les configurations classiques des distributions ou par une découverte automatique utilisant le système de paquets, simplifiant ainsi l’écriture des associations. 6.2.4 Propriétés

Une fois les contextes définis et associés aux ressources, il est possible de définir les propriétés répondant aux besoins de sécurité. Nous séparons ces propriétés en trois niveaux qui correspondent aux niveaux IaaS, PaaS et SaaS de l’informatique en nuage. Afin de simplifier cette politique, nous ne nous intéressons ici qu’aux applications spécifiques au cas d’usage : la politique de base du système (non spécifique au cas d’usage) n’est pas présentée.

6.2.4.1 IaaS

La première partie de la politique concerne la partie IaaS du cas d’usage. Elle se divise en deux parties : la politique à appliquer sur les machines physiques (qui peut être définie par le fournisseur de l’infrastructure) et celle à appliquer sur les VM (qui peut être définie par l’administrateur des VM).

Machines physiques La politique appliquée sur les machines physiques correspond à celle demandée par le fournisseur de l’architecture et est présentée au listing 6.10.

1 Authentication (anyone, ServiceSSH, CloudProvider);

2 Access (SSHPort, anyIP);

3 Isolation (VMs);

Listing 6.10 – Politique des machines physiques

La première propriété permet au fournisseur de l’infrastructure (CloudProvider) de se connecter en SSH sur les machines physiques. Le premier contexte de la propriété d’authentification indique la machine d’où provient la tentative de connexion (ici, toutes les machines), le deuxième spécifie le service sur lequel l’authentification se produit (ici, SSH), et le dernier les utilisateurs autorisés à se connecter. La seconde propriété demande l’ouverture du port d’écoute de SSH afin de permettre les connexions. Enfin, la troisième propriété demande l’isolation de l’ensemble des VM déployées sur cette machine physique. Machines virtuelles La deuxième politique de niveau IaaS est celle établie par le client IaaS et elle a pour but de protéger le système des machines virtuelles. Considérons la politique du listing 6.11 protégeant le système de la VM Apache.

1 Authentication (HostServerWEB, ServiceSSH, "TenantAdmin|TenantOperator");

2 Authentication (HostReverseProxy, ServiceSSH, "TenantAdmin|TenantOperator");

4 Access (SSHPort, HostServerWEB);

5 Access (SSHPort, HostReverseProxy);

6.2. POLITIQUE DE SÉCURITÉ

Les deux premières propriétés gèrent les authentifications possibles sur la VM. Ainsi, les connexions SSH sont autorisées pour l’administrateur de la VM (TenantOperator) et pour l’administrateur des applications (TenantAdmin) en local (HostServerWEB) et depuis la machine proxy (HostReverseProxy). Les deux autres propriétés permettent d’ouvrir le port SSH (pour les connexions locales ou en provenance du proxy).

Les politiques pour les autres VM sont similaires à celle du listing 6.11 : des propriétés d’authentification par SSH (et éventuellement sur les autres services) et des propriétés d’accès pour ouvrir des ports réseaux.

Machines physiques et virtuelles Certaines propriétés de la politique sont appliquées sur l’ensemble des machines, à la fois physiques et virtuelles. Tout d’abord, une politique de base peut être utilisée pour protéger le système (par exemple, protéger les applications et les logs systèmes). Cependant, cette partie de la politique n’est pas détaillée ici et nous choisissons de concentrer cette expérimentation sur la protection de l’architecture logicielle et non sur le système.

Ainsi, dans notre cas d’usage, le politique commune est constituée d’une propriété d’assurance (listing 6.12) permettant de fixer la fréquence des tests à eﬀectuer concernant l’état des mécanismes et l’application des propriétés. La première ligne définit un contexte contenant une fréquence (10 minutes). La deuxième est la propriété d’assurance : les scripts générés pour vérifier les mécanismes et les propriétés seront donc exécutés à la fréquence spécifiée.

1 Frequency = (Tests.Frequency="10m");

2 Assurance (Frequency);

Listing 6.12 – Propriété d’assurance

Cette propriété d’assurance est une version simple. Elle pourrait être affinée en pas-sant en paramètre des contextes pour sélectionner les différents tests à effectuer. Les tests pourraient alors être exécutés à des fréquences différentes selon le type des tests et leur criticité.

6.2.4.2 PaaS

La politique de niveau PaaS présentée au listing 6.13 permet de protéger les applica-tions fournies par la plateforme. Elle est donc définie par l’administrateur de l’architecture logicielle, c’est-à-dire le client du PaaS.

1 Authentication (HostClient, ServiceWEBAPPS, "User");

3 @Isolation (DomainWEB, ServiceWeb);

4 @Isolation (DomainWEBAPPS, ServiceWEBAPPS);

6 Confidentiality_access_control (LogWEB, TenantOperator);

7 Confidentiality_access_control (LogWEB, TenantAdmin);

8 Confidentiality_access_control (LogWEBAPPS, TenantAdmin);

10 Confidentiality_access_control (ConfigWEB, TenantAdmin);

11 Confidentiality_access_control (FileWEB, TenantAdmin);

12 Confidentiality_access_control (ConfigWEBAPPS, TenantAdmin);

13 Confidentiality_access_control (FileWEBAPPS, TenantAdmin);

15 Integrity (ConfigWEB, TenantAdmin);

16 Integrity (ConfigWEBAPPS, TenantAdmin);

18 Executable (BinaryWEB, TenantAdmin);

19 Executable (BinaryWEBAPPS, TenantAdmin);

21 Access (WEBAPPSPort, HostClient);

Listing 6.13 – Politique PaaS des VM Apache

La première propriété autorise la connexion de l’utilisateur User sur l’application Apa-cheGUI depuis la VM Client.

Les deux propriétés suivantes font appel à la classe @Isolation pour isoler les ap-plications Apache, PHPMyAdmin et ApacheGUI. La propriété Sandbox_App, définie au listing 6.14, fait partie de cette classe et correspond aux contextes passés en arguments. 1 boolean Sandbox_App (Domain SCDom, Type.Active SCApp) {

2 enforcement && assurance {

3 Isolation_System (SCDom);

4 Confidentiality_access_control (SCDom:(Type.Passive.Data.File=".*"), SCDom:

SCApp);

5 Integrity (SCDom:(Type.Passive.Data.File.Configuration=".*"), SCDom:SCApp);

6 Integrity (SCDom:(Type.Passive.Data.File.Logs=".*"), SCDom:SCApp);

7 Integrity (SCDom:(Type.Passive.Data.File.Key=".*"), SCDom:SCApp);

8 Integrity (SCDom:(Type.Passive.Data.File.Temporary=".*"), SCDom:SCApp);

9 Integrity (SCDom:(Type.Passive.Data.File.Binary=".*"));

10 Integrity (SCDom:(Type.Passive.Data.File.Executable=".*"));

11 Executable (SCDom:(Type.Passive.Data.File.Executable=".*"), SCDom:SCApp);

12 }

13 }

Listing 6.14 – Propriété d’isolation système d’une application

La propriété Sandbox_App isole, au niveau système, un domaine SCDom (ligne 3) qui est lié à une application ou un service SCApp, puis définit les interactions autorisées à l’intérieur de ce domaine. Ainsi, l’ensemble des fichiers sont accessibles en lecture par une application appartenant à ce domaine (ligne 4). Les fichiers de configuration, de logs, de clefs, et les fichiers temporaires peuvent être édités par cette application (lignes 5 à 8). Les fichiers binaires et exécutables ne peuvent pas être édités (lignes 9 et 10). Enfin, les applications du domaine sont autorisées à exécuter les fichiers exécutables liés au domaine (ligne 11). Cette propriété est générique et correspond aux besoins de sécurité que l’on peut appliquer sur un grand nombre d’applications ou services systèmes. Notons que si, pour un domaine, aucune ressource n’est associée à un contexte (par exemple, aucune clef de chiﬀrement), la propriété interne correspondante est ignorée mais la propriétéSandbox_App

est appliquée.

Lorsque les domaines DomainWEB et DomainWEBAPPS sont isolés, des interactions supplémentaires sont définies au listing 6.13 afin de correspondre aux besoins de sécurité définis. L’administrateur du système (TenantOperator) est autorisé à lire les fichiers de logs du serveur Web (ligne 6), et l’administrateur des applications peut lire les logs du serveur Web et des applications (lignes 7 et 8). L’administrateur des applications est quant à lui autorisé à lire les fichiers de configuration et les fichiers divers des applications (lignes 10 à 13) et à éditer les fichiers de configuration (lignes 15 et 16). De plus, il peut exécuter les fichiers binaires (lignes 18 et 19) du domaine afin, par exemple, de redémarrer le service associé. Enfin, le port utilisé par ApacheGUI est ouvert (ligne 21) et accessible uniquement depuis le client. Des politiques similaires sont définies pour les applications des VM Proxy et MySQL. Elles sont cependant plus simples puisque ces VM n’ont qu’un seul domaine applicatif à sécuriser (respectivement DomainWEB et DomainSQL).

6.3. APPLICATION ET ASSURANCE 6.2.4.3 SaaS

La dernière partie de la politique est celle du niveau SaaS (voir listing 6.15). Elle permet à l’utilisateur des applications d’accéder à ses applications allouées (ApacheGUI, PHPMyAdmin) afin de créer des sites Web.

1 Access (WEBPort, AnyIP);

2 Confidentiality (HostReverseProxy, "HostClient|HostServerWEB|HostServerSQL");

Listing 6.15 – Politique SaaS des VM Apache

La première propriété ouvre le port Web à toutes les adresses IP, autorisant ainsi les connexions au site Web. La deuxième propriété crée un tunnel entre le client et les VM Apache et MySQL correspondantes : l’utilisateur peut ainsi se connecter sur ses VM en passant par le proxy, de manière transparente. Cette propriété de confidentialité réseau est appliquée sur chaque VM intervenant dans le quadruplet de VM Client / Reverse Proxy / Apache / MySQL, afin de créer, par exemple, un tunnel ou un VPN en fonction des mécanismes disponibles sur chaque hôte. Par conséquent, les mécanismes choisis doivent être compatibles au niveau réseau afin d’assurer une cohérence de l’application.

De plus, dans le cas de l’utilisation d’un VPN, le port sur lequel le serveur écoute est choisi par le module d’extension. Par conséquent, le module utilise les capacités internes du SEE pour partager le numéro du port qui a été choisi avec les autres SEE interve-nant dans cette propriété. On remarque aussi que la propriété de confidentialité réseau (section 3.5.2.2) ne contient pas de capacité d’ouverture de port. Cette ouverture est donc gérée par le module lui-même qui demande donc au SEE l’application d’une nouvelle ca-pacité, induite par le fonctionnement spécifique du module d’extension choisi.

Cette propriété étant établie entre un triplet de VM Client / Apache / MySQL, les communications entre VM de triplets diﬀérents ne sont pas autorisées. Ainsi, un utilisateur sur la VM Client du premier triplet pourra accéder au serveur Web du premier triplet, mais pas à ceux des autres triplets.

Enfin, notons que nous ne définissons pas de propriété protégeant les informations sto-ckées dans la base de données ou l’exécution de l’application. De telles propriétés pourraient être ajoutées, cependant nous avons choisi de concentrer ces travaux sur les mécanismes systèmes et réseaux, et non sur les mécanismes applicatifs. Les modules d’extensions cor-respondant aux mécanismes applicatifs qui pourraient être utilisés ne sont donc pas actuel-lement implémentés.

6.3 Application et assurance

Cette section décrit l’application des diﬀérents niveaux de politiques sur les machines, en fonction de la configuration et des mécanismes disponibles sur chaque machine. Nous considérons le cas de l’application idéale (tous les mécanismes sont disponibles) et le mode de sélection Défaut. De plus, les tests d’assurance, exécutés par le SEE, sont ici simulés manuellement. Leurs résultats sont donc également présentés. Notons que nous ne détaillons pas les configurations générées : des exemples ont été donnés au chapitre 5.

Dans le document Application et assurance autonomes de propriétés de sécurité dans un environnement d’informatique en nuage (Page 143-152)