Isolation des ressources

3DS OUTSCALE propose des solutions d’Infrastructure as a Service (IaaS) et gère plus de 30000 machines virtuelles.

Le contrôle de l’isolation des ressources est indispensable pour garantir la sécurité de nos utilisateurs. Ce document explique comment les ressources sont isolées les unes des autres et comment les utilisateurs peuvent gérer une partie de cette isolation selon leurs besoins.

Isolation de l’API

Authentification

L’API (Application Programming Interface) de 3DS OUTSCALE expose des objets ou ressources logiques qui peuvent être manipulés.

Chaque action liée à l’API (lecture, écriture, association, etc.) est réalisée à distance par des utilisateurs authentifiés.

Les utilisateurs signent leurs requêtes à l’aide de la méthode AWS Signature (v4). Cette méthode garantit l’identité de l’utilisateur et l’intégrité des requêtes.

Une fois signée, la requête est transmise à 3DS OUTSCALE par l’intermédiaire d’une connexion https sécurisée (TLS).

Accès aux ressources

Une fois l’utilisateur authentifié et l’intégrité de la requête validée, le logiciel TINA garantit l’isolation des ressources et effectue des actions uniquement sur les ressources de l’utilisateur authentifié.

Le logiciel TINA est testé à l’aide des méthodes sécurisées de développement de 3DS OUTSCALE.

Une équipe d’assurance qualité dédiée développe et automatise ces tests avant et après chaque déploiement en production.

Isolation du réseau

Les security groups

Un security group est une ressource logique gérée par l’utilisateur et qui agit comme un pare-feu logique. Les security groups contiennent une liste de règles de flux réseau qui autorisent ou non ces flux (par défaut, tous les flux sont interdits).

Un security group peut ensuite être associé à une ressource spécifique comme une machine virtuelle ou une gateway. Ce cadre de sécurité permet aux utilisateurs de gérer l’isolation de leurs ressources au niveau du réseau.

Lorsqu’un security group est associé ou modifié, ce dernier adopte les règles de pare-feu correspondantes, qui sont déployées dans l’architecture TINA.

Le Cloud public

Le Cloud public permet aux utilisateurs de créer des machines virtuelles pouvant accéder à Internet.

Les machines virtuelles créées sur le réseau du Cloud public ne peuvent pas recevoir de communication d’une autre machine virtuelle, sauf si leur propriétaire a explicitement autorisé un flux entrant spécifique. Par conséquent, les utilisateurs utilisent le même réseau logique, ce qui signifie qu’une mauvaise configuration des règles d’un security group (pare-feu logique) peut provoquer une brèche dans l’isolation, ce qui n’est pas le cas avec les Virtual Private Clouds (voir ci-dessous).

Les flux réseau sont gérés par les utilisateurs à l’aide des règles des security groups. Une machine virtuelle a toujours un security group, qui est vide par défaut (cela signifie qu’aucun flux n’est autorisé à accéder à la machine virtuelle).

Les Virtual Private Clouds

Comparable aux VLAN et VXLAN, un Virtual Private Cloud (VPC) est un réseau logique. Chaque utilisateur peut posséder et gérer plusieurs VPC en même temps. Chaque VPC est entièrement isolé des autres VPC, sauf si ces derniers appartiennent au même utilisateur.

De par sa conception, un VPC ne présente aucun risque de mauvaise configuration par l’utilisateur, contrairement au Cloud public. Il n’y a donc aucun risque de brèche dans l’isolation des ressources.

Les réseaux VPC étant isolés, les utilisateurs sont libres de choisir l’adressage réseau au moment de la création du VPC sans qu’il n’y ait de conflit avec un réseau déjà existant.

Par défaut, aucune route Internet n’est configurée sur un VPC, ce qui permet ainsi d’isoler entièrement le réseau de toute autre ressource externe.

Les subnets

Les subnets sont un sous-ensemble d’un réseau VPC. Ils peuvent communiquer seulement grâce à l’ajout de routes, qui sont contrôlées par l’utilisateur à l’aide d’objets logiques appelés route tables.

Les machines virtuelles situées dans un subnet d’un VPC ont toujours au moins un security group, ce qui isole l’accès à la machine virtuelle.

Les subnets faisant partie d’un réseau VPC, ils sont donc entièrement isolés.

Communication externe

Afin de permettre aux utilisateurs de configurer une route Internet par défaut, une Internet gateway facultative peut être ajoutée ou supprimée d’un VPC.

D’autres types de trafic peuvent être routés vers un VPC. Par exemple, un utilisateur peut configurer une Virtual Private Gateway (VPN) afin de pouvoir accéder à son réseau VPC.

Les routes et flux réseaux peuvent être décrits et gérés via l’API de 3DS OUTSCALE. De cette façon, les utilisateurs gèrent l’accès à leurs ressources et leur isolation.

Isolation des machines virtuelles

Hyperviseur et isolation des machines virtuelles

Les machines virtuelles sont une simulation fonctionnelle d’un ordinateur physique. Cette simulation est calculée en temps réel et sur du véritable matériel (hyperviseur).

Chaque hyperviseur contient des processeurs avec des instructions de virtualisation Intel x86 (famille vmx).

Ces propriétés de processeurs Intel ont été créées dans le but d’accélérer les simulations et d’isoler les machines virtuelles en cours de fonctionnement de l’hyperviseur.

Le contrôle de l’isolation du calcul et de la mémoire d’une machine virtuelle est réalisée par le système d’exploitation de l’hyperviseur. 3DS OUTSCALE utilise principalement le kernel Linux avec le module KVM et QEMU.

Isolation des machines virtuelles sur un même hyperviseur

L’isolation de la puissance de calcul et de la mémoire d’une machine virtuelle est effective grâce à la méthode citée ci-dessus.

Les machines virtuelles en cours de fonctionnement sur le même hyperviseur ne peuvent interagir ou s’altérer sans communiquer via le réseau.

Chaque communication réseau d’une machine virtuelle se fait par une interface réseau virtuelle spécifique (vNIC). Une interface réseau virtuelle (vNIC) assure l’isolation grâce à l’encapsulation et la création d’un tunnel vers un pare-feu spécifique.

Les pare-feux sont gérés par 3DS OUTSCALE et sont responsables de l’application, du filtrage et du routage en fonction des configurations spécifiques (et limitées) que les utilisateurs définissent pour leurs route tables et règles de security groups.

Cette architecture réseau assure une isolation contrôlée des communications entre machines virtuelles.

De plus, le client peut choisir du matériel dédié pour une sécurité renforcée.

Isolation du stockage

3DS OUTSCALE propose deux types de stockage persistants : le Block Storage Unit (BSU) et l’OUTSCALE Object Storage (OOS).

Block Storage Unit

Un BSU est un stockage logique et persistant, attaché à une machine virtuelle. Il peut être contrôlé par l’utilisateur via l’API et via sa machine virtuelle.

Lorsqu’il est attaché à une machine virtuelle, un BSU est détecté comme étant un block device sur lequel l’utilisateur est libre d’écrire des données (à travers un système de fichiers, par exemple).

Le fait d’attacher un BSU à une machine virtuelle est géré par le logiciel TINA qui vérifie que l’utilisateur est autorisé à attacher le disque à une machine virtuelle spécifique.

De cette façon, un utilisateur ne peut pas accéder aux données sauvegardées sur le BSU d’un autre utilisateur. Ainsi, l’isolation des BSU est assurée.

OUTSCALE Object Storage

Chaque objet OOS qui contient des données est contenu dans un bucket OOS.

Les droits d’accès aux objets et buckets OOS sont entièrement gérés par les utilisateurs. Un utilisateur non autorisé ou un utilisateur anonyme ne peut pas accéder à des données utilisateur spécifiques.

L’isolation est réalisée à travers des permissions d’accès. Le système de permissions est géré par le logiciel OOS, qui est lui-même basé sur la solution RING de Scality avec le support S3.

Pages connexes

AWS™ et Amazon Web Services™ sont des marques de commerce d'Amazon Technologies, Inc. ou de ses affiliées aux États-Unis et/ou dans les autres pays.