> For the complete documentation index, see [llms.txt](https://docs.verge.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.verge.io/learn-the-platform/fr/module-7-multi-tenant/05-isolation-security.md).

# Isolation et sécurité des tenants

## Le modèle d'isolation de VergeOS

La multi-location de VergeOS repose sur **isolation architecturale** — et non sur une simple séparation basée sur des politiques. Chaque locataire est un centre de données virtuel (VDC) entièrement encapsulé, avec sa propre pile réseau, des volumes de stockage exclusifs et une frontière administrative indépendante. Cela contraste avec les plateformes qui s'appuient sur des VLAN, des pools de ressources ou des règles RBAC pour séparer les locataires au sein d'un plan de gestion partagé.

Le modèle d'isolation repose sur quatre piliers :

```mermaid
graph TB
    subgraph isolation["Modèle d'isolation des locataires VergeOS"]
        direction LR
        NET["Réseau<br/>Encapsulation<br/>──────<br/>Isolation L2/L3<br/>par locataire"]
        STOR["Stockage<br/>Isolation<br/>──────<br/>Volumes exclusifs<br/>par locataire"]
        AUTH["Gestion des utilisateurs<br/>indépendante<br/>──────<br/>Locale, parent,<br/>ou IdP/OIDC"]
        RES["Garanties de ressources<br/>──────<br/>CPU/RAM/stockage<br/>quotas appliqués"]
    end

    style isolation fill:#e8f5e9,stroke:#2e7d32
    style NET fill:#e3f2fd,stroke:#1565c0
    style STOR fill:#e3f2fd,stroke:#1565c0
    style AUTH fill:#e3f2fd,stroke:#1565c0
    style RES fill:#e3f2fd,stroke:#1565c0
```

***

## Encapsulation réseau

L'encapsulation réseau est le fondement de l'isolation des locataires. Lorsqu'un locataire est créé, VergeOS provisionne automatiquement un réseau virtuel qui **agrège et encapsule tout le trafic de ce locataire**. Du point de vue du locataire, il s'agit de son réseau physique — il ne peut ni voir ni interagir avec le trafic d'un autre locataire.

### Fonctionnement

* Chaque locataire reçoit son propre **réseau DMZ** qui sert d'épine dorsale de routage pour tous les réseaux du locataire
* Le trafic du locataire est encapsulé aux **couches 2 et 3**, empêchant la communication inter-locataires au niveau du réseau
* Le réseau encapsulé permet aux nœuds du locataire de communiquer en toute sécurité même lorsqu'ils s'exécutent sur différents hôtes physiques
* Les locataires peuvent créer un nombre virtuellement illimité de réseaux internes dans leur propre environnement

### Pourquoi c'est important

Contrairement à la segmentation basée sur les VLAN — où une balise VLAN mal configurée ou un commutateur compromis pourrait exposer le trafic entre locataires — l'encapsulation réseau de VergeOS offre **une isolation réseau zéro confiance** par défaut. Un locataire ne peut pas atteindre le réseau d'un autre locataire, même s'ils partagent la même infrastructure physique.

```mermaid
graph TB
    subgraph host["Système VergeOS physique"]
        EXT["Réseau externe<br/>(LAN/WAN amont)"]
        DMZ["DMZ de l'hôte"]

        subgraph t1["Locataire A (encapsulé)"]
            T1_DMZ["DMZ du locataire A"]
            T1_INT1["Réseau interne 1"]
            T1_INT2["Réseau interne 2"]
            T1_INT1 --> T1_DMZ
            T1_INT2 --> T1_DMZ
        end

        subgraph t2["Locataire B (encapsulé)"]
            T2_DMZ["DMZ du locataire B"]
            T2_INT1["Réseau interne 1"]
            T2_INT2["Réseau interne 2"]
            T2_INT1 --> T2_DMZ
            T2_INT2 --> T2_DMZ
        end

        T1_DMZ --> DMZ
        T2_DMZ --> DMZ
        DMZ --> EXT
    end

    style t1 fill:#e3f2fd,stroke:#1565c0
    style t2 fill:#fff3e0,stroke:#e65100
    style host fill:#e8f5e9,stroke:#2e7d32
```

***

## Volumes de stockage dédiés

Chaque locataire reçoit des **volumes de stockage dédiés** dans le vSAN, présentés au locataire comme s'il disposait de son propre système de stockage. L'isolation est appliquée logiquement via les frontières du système de fichiers du conteneur — un locataire ne peut pas voir ni accéder aux données d'un autre locataire — tandis que le vSAN sous-jacent déduplique les blocs à l'échelle de l'ensemble du cluster pour plus d'efficacité.

Caractéristiques clés :

* **Provisionnement par locataire** — Le stockage est provisionné par niveau (NVMe, SSD, HDD) avec des allocations de capacité spécifiques
* **Déduplication indépendante** — Les statistiques de déduplication de chaque locataire ne reflètent que ses propres données. La déduplication fonctionne au niveau des blocs du vSAN sur l'ensemble du système ; les métriques visibles par le locataire n'affichent que les économies par locataire
* **Provisionnement fin** — Le stockage du locataire est provisionné en mode fin. Un disque VM de 4 To qui ne contient que 200 Go de données consomme environ 200 Go de capacité vSAN (moins les économies de déduplication)
* **Prise en charge du chiffrement** — Le chiffrement vSAN (AES-256, configuré à l'installation) s'applique à toutes les données, y compris les volumes des locataires

***

## Gestion indépendante des utilisateurs

Chaque locataire gère ses propres comptes utilisateurs et son authentification de manière indépendante. Trois modèles d'authentification sont disponibles :

| Modèle                        | Description                                                                                                                                                                            | Cas d'utilisation                                                                 |
| ----------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------- |
| **Utilisateurs locaux**       | L'administrateur du locataire crée et gère directement les comptes utilisateurs dans l'interface du locataire                                                                          | Petits locataires, environnements autonomes                                       |
| **VergeOS parent (via OIDC)** | Le locataire s'authentifie via une application OIDC définie sur le système VergeOS parent, de sorte que les connexions du locataire s'appuient sur l'annuaire d'utilisateurs du parent | Fournisseurs de services gérés qui contrôlent centralement l'accès des locataires |
| **IdP tiers (via OIDC)**      | Le locataire s'intègre à un fournisseur d'identité externe (Okta, Azure AD/Entra, Google Cloud Identity, etc.) via OIDC                                                                | Locataires d'entreprise disposant déjà d'une infrastructure d'identité            |

L'intégration OIDC est configurée pour chaque locataire lors de la création ou de la modification. Lorsqu'une application OIDC est sélectionnée, le locataire utilise le fournisseur d'identité externe pour l'authentification tout en conservant une autorisation locale (permissions et rôles).

***

## Pass-through de couche 2 vers les locataires

Dans certains scénarios, un locataire a besoin d'un accès direct de couche 2 à un VLAN physique — par exemple, pour se connecter à un lien WAN dédié, à un réseau de stockage physique ou à des applications héritées nécessitant une adjacence L2.

VergeOS fournit **Réseaux de couche 2 des locataires** (versions récentes de VergeOS) pour un pass-through VLAN simplifié :

### Fonctionnement

1. L'administrateur de l'hôte se rend dans **Locataires → \[Locataire] → Réseaux Layer2 → Nouveau**
2. Sélectionne le réseau externe de couche 2 (VLAN) à faire passer
3. Active le pass-through

VergeOS crée automatiquement trois composants dans le locataire :

* Un **Interface NIC** sur le nœud du locataire connecté au VLAN
* Un **Réseau physique** (infrastructure backend)
* Une **Réseau externe** auquel les VM du locataire peuvent se connecter

### Liste de vérification

| Niveau             | Cochez                                                                                     |
| ------------------ | ------------------------------------------------------------------------------------------ |
| **Hôte**           | Le réseau de couche 2 apparaît dans la liste Layer2 Networks du locataire, Activé = ON     |
| **Tenant**         | Les réseaux Externe et Physique apparaissent dans la liste Networks du locataire           |
| **Infrastructure** | Les ports du commutateur physique transportent le VLAN vers les bons nœuds                 |
| **Connectivité**   | Une VM de test sur le réseau Externe du locataire peut atteindre les périphériques du VLAN |

### Restrictions importantes

{% hint style="warning" %}
**VLAN réservés**

VLAN **1, 100, 101 et 102** sont réservés au trafic interne de VergeOS et ne peuvent pas être utilisés pour le pass-through de couche 2.
{% endhint %}

{% hint style="warning" %}
**Ne pas étiqueter le réseau externe du locataire**

Le réseau Externe créé dans le locataire est déjà étiqueté pour le VLAN correct. Ne **pas** pas ajouter de balise VLAN au réseau Externe côté locataire — c'est une erreur de configuration courante qui rompra la connectivité.
{% endhint %}

### Procédure de suppression

La suppression d'un réseau de couche 2 du locataire nécessite un ordre précis :

1. **Désactiver** le réseau de couche 2 côté hôte
2. **Supprimer** le réseau de couche 2 côté hôte (l'interface NIC est automatiquement supprimée)
3. Dans le locataire : supprimez le **Externe** réseau d'abord, puis le **Physique** réseau

{% hint style="success" %}
Supprimez toujours le réseau Externe avant le réseau Physique dans le locataire. Le réseau Externe référence le réseau Physique comme interface, donc inverser l'ordre provoquera une erreur.
{% endhint %}

***

## Micro-segmentation au sein des locataires

Chaque locataire peut mettre en œuvre sa propre stratégie de micro-segmentation en utilisant les mêmes outils réseau disponibles au niveau de l'hôte :

* **Réseaux internes** — Chaque réseau interne est un segment isolé et sécurisé par défaut. Aucun trafic n'entre ni ne sort tant que des règles explicites n'ont pas été ajoutées.
* **Règles réseau** — Règles de pare-feu granulaires (Accept, Drop, Reject), NAT/PAT et routes statiques par réseau
* **Alias réseau** — Regrouper des adresses IP ou des plages CIDR pour simplifier la gestion des politiques
* **Miroir de port** — Répliquer le trafic d'un réseau vers une interface NIC de VM pour analyse

Cela permet **les principes zéro confiance** au sein de chaque locataire — les charges de travail sont isolées par défaut et communiquent uniquement via des chemins explicitement autorisés.

***

## Garanties de ressources

L'allocation des ressources des locataires est appliquée au niveau de la plateforme :

* **CPU et RAM** — Les cœurs et la RAM attribués aux nœuds du locataire sont des allocations dédiées ; le système hôte prend en compte les ressources des nœuds du locataire dans sa planification
* **Stockage** — Le stockage provisionné par niveau définit la capacité du locataire. Bien que le stockage provisionné ne constitue pas une limite stricte, des alertes de journal sont déclenchées lorsqu'un locataire approche de son seuil
* **Bande passante réseau** — Une limitation de débit peut être appliquée par règle réseau pour le façonnage du trafic

***

## Surveillance des locataires depuis le parent

Le système hôte (parent) conserve une visibilité complète sur les opérations des locataires sans violer l'isolation des locataires.

### Tableau de bord de tous les locataires

Le tableau de bord de tous les locataires fournit une vue d'ensemble de tous les locataires avec :

* **Indicateurs d'état** — Nombre de locataires et de nœuds de locataire sous tension
* **Listes des plus fortes consommations** — Utilisation CPU, RAM, stockage et réseau classée par locataire
* **Liens rapides** — Cliquez sur n'importe quel locataire pour accéder à son tableau de bord individuel

### Tableau de bord individuel du locataire

Le tableau de bord de chaque locataire affiche :

* **Utilisation du CPU, de la RAM et du stockage** dans des graphiques par intervalles de 5 minutes
* **battement à 5 secondes** statistiques pour la surveillance en temps réel
* **Entrées de journal** avec les erreurs mises en évidence en rouge
* **Métriques de stockage** — Valeurs utilisées, provisionnées et allouées

### Rapports d'utilisation pour la facturation

VergeOS stocke les statistiques d'utilisation par locataire pour prendre en charge **la facturation au 95e percentile**:

1. Accédez au tableau de bord du locataire → **Historique**
2. Sélectionnez une période de filtrage (mois, plage personnalisée)
3. Cliquez sur **Appliquer** pour générer des graphiques montrant la moyenne, le maximum et le 95e percentile
4. Exporter au format CSV pour l'intégration à la facturation

Vous pouvez aussi configurer un **abonnement** (Système → Abonnements → Nouveau) avec :

* Type de cible : *Tableau de bord des locataires*
* Type : *Planifié*
* Profil : *Utilisation des locataires*

Cela fournit des rapports d'utilisation automatisés par e-mail selon la planification configurée.

### Exposition des instantanés

Lorsque l' **option Exposer les instantanés système** est activée pour un locataire, celui-ci peut parcourir les instantanés disponibles de l'hôte et télécharger en libre-service son propre instantané de locataire à partir des horodatages d'instantanés du fournisseur. Cela permet aux locataires de restaurer leurs propres systèmes sans intervention de l'administrateur de l'hôte.

### Audit et alertes

* **Les abonnements** peuvent déclencher des alertes e-mail en cas d'erreurs d'état du locataire, d'avertissements ou de dépassement de seuil
* **Les rapports planifiés** peuvent envoyer aux administrateurs des résumés quotidiens/hebdomadaires du tableau de bord
* Le **L'API** peut exporter les données d'utilisation des locataires vers des systèmes de facturation ou de surveillance externes

***

## Instantanés et restaurations des locataires

Chaque locataire peut être instantané et restauré indépendamment :

* **Instantanés par locataire** — L'hôte peut prendre des instantanés de locataires individuels sans affecter les autres locataires
* **Instantanés contrôlés par le locataire** — Les locataires peuvent gérer leurs propres planifications d'instantanés et politiques de rétention au sein de leur VDC
* **Restauration granulaire** — Restaurer un locataire entier, des VM individuelles ou des données spécifiques à partir de n'importe quel point d'instantané
* **Réplication DR** — Les instantanés des locataires peuvent être répliqués vers des sites distants via la synchronisation de site, avec des politiques DR par locataire

***

## Bonnes pratiques

### Par défaut, utiliser l'encapsulation

Utilisez l'encapsulation réseau intégrée de VergeOS pour tous les locataires. Ne configurez le pass-through de couche 2 que lorsqu'un besoin spécifique d'accès direct au VLAN existe.

### Documenter les affectations VLAN

Conservez une documentation claire indiquant quels VLAN sont transmis à quels locataires, y compris les identifiants VLAN, les usages et les configurations des ports de commutateur.

### Réseau au moindre privilège

Au sein de chaque locataire, partez de réseaux internes sécurisés par défaut et n'ouvrez l'accès que via des règles de pare-feu explicites. Suivez les principes zéro confiance.

### Surveiller les seuils de stockage

Configurez des abonnements pour alerter lorsque le stockage d'un locataire approche des limites provisionnées. Le provisionnement fin signifie que l'alloué peut largement dépasser l'utilisé — surveillez « utilisé » pour suivre la consommation réelle.

### Utiliser OIDC pour les locataires d'entreprise

Pour les locataires d'entreprise disposant déjà d'une infrastructure d'identité, configurez l'intégration OIDC plutôt que de gérer des comptes utilisateurs locaux dans chaque locataire.

### Ordre de suppression L2

Lors de la suppression du pass-through de couche 2, désactivez et supprimez toujours d'abord côté hôte, puis nettoyez le réseau Externe avant le réseau Physique à l'intérieur du locataire.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.verge.io/learn-the-platform/fr/module-7-multi-tenant/05-isolation-security.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
