Isolation des ressources

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).

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.

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 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 Nets (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).

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

De par sa conception, un Net 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 Net étant isolés, les utilisateurs sont libres de choisir l’adressage réseau au moment de la création du Net 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 Net, ce qui permet ainsi d’isoler entièrement le réseau de toute autre ressource externe.

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.

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.

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.

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