Pilier Security sur OUTSCALE

Le pilier Security couvre l’identité (EIM), le réseau (Net, security groups, isolation), le chiffrement (at-rest natif sur BSU/OOS, in-transit via TLS), la gestion des secrets (typiquement OpenBao/Vault, OUTSCALE n’expose pas de KMS managé natif en 2026), la journalisation des appels API (OMS) et la conformité réglementaire. Sur OUTSCALE, il prend une dimension supplémentaire grâce à la qualification SecNumCloud 3.2 sur la région cloudgouv-eu-west-1, à condition de configurer correctement la couche client. Cette page formule les questions clés, propose une checklist actionnable, deux ADR types et les points d’audit correspondants.

Le pilier en deux phrases

Security évalue la capacité d’une architecture à protéger les actifs (données, identités, secrets, infrastructure) contre les menaces internes et externes, et à prouver cette protection à un auditeur. Sur OUTSCALE, il se matérialise par une discipline EIM (moindre privilège, MFA, rotation), une segmentation réseau stricte (Net + Subnets + Security Groups), un chiffrement systématique des volumes BSU et des objets OOS, une gestion centralisée des secrets via une solution dédiée, et une journalisation OMS exploitable.

Les questions clés

Une architecture qui revendique une posture Security doit pouvoir répondre aux questions suivantes :

Identités humaines — chaque utilisateur a-t-il un compte EIM nominatif avec MFA obligatoire ? Les comptes partagés sont-ils interdits par politique ?
Identités machines — les workloads utilisent-ils des rôles EIM plutôt que des access keys longues durées ? Quand des access keys sont nécessaires, sont-elles rotées tous les 90 jours maximum ?
Moindre privilège — les politiques EIM sont-elles scopées aux ressources nécessaires, ou applique-t-on un wildcard *:* par confort ?
Segmentation réseau — les workloads sensibles sont-ils dans des subnets privés avec sortie via NAT Service contrôlé ? Les Security Groups appliquent-ils le pattern SG-to-SG plutôt que des CIDR larges ?
Chiffrement at-rest — les volumes BSU sont-ils créés avec chiffrement activé ? Les objets OOS sont-ils stockés avec chiffrement serveur ?
Chiffrement in-transit — toutes les communications utilisent-elles TLS 1.2+ ? Les certificats sont-ils gérés (renouvellement automatique, monitoring d’expiration) ?
Gestion des secrets — les secrets sont-ils stockés dans un gestionnaire dédié (OpenBao, Vault, ou équivalent) plutôt qu’en variables d’environnement, fichiers .env ou secrets Kubernetes en clair ?
Journalisation — OMS est-il activé, exporté sur un compte d’audit séparé avec object lock, et exploité par un SIEM ou par des règles d’alerte ?
Conformité SecNumCloud — si la région cloudgouv-eu-west-1 est utilisée, la couche cliente respecte-t-elle les exigences SecNumCloud 3.2 (chiffrement, journalisation, gestion des accès) ?
Tests d’intrusion — l’environnement subit-il un pentest annuel par un tiers qualifié, avec suivi des vulnérabilités jusqu’à correction ?

Une équipe qui répond « non » à plus de deux questions sur les six premières expose son organisation à un risque significatif d’incident de sécurité.

Application sur OUTSCALE

Identités EIM — humaines vs machines

Sur OUTSCALE, EIM (Elastic Identity Management) est l’équivalent fonctionnel d’AWS IAM. Il distingue trois types d’entités :

Utilisateurs — comptes nominatifs pour les humains. Doivent porter une MFA activée et une politique scopée à leur rôle (admin, dev, audit, lecture seule).
Groupes — collections d’utilisateurs partageant un rôle. Les politiques s’attachent au groupe, pas à l’utilisateur, pour faciliter le turnover.
Access keys — paires de clés pour l’accès programmatique. À utiliser uniquement quand un rôle EIM n’est pas applicable (CI externe, agent on-premise).

Pour les workloads exécutés dans le cloud OUTSCALE, privilégier les rôles EIM quand c’est possible : un workload OKS récupère ses credentials via un mécanisme dédié sans avoir à manipuler de fichier de clés.

Segmentation réseau

Le plan d’adressage d’un Net OUTSCALE doit séparer publique, privée et data. La règle classique :

Subnet public — héberge uniquement les bastions et les load balancers. Pas de workload applicatif direct.
Subnet privé — workloads applicatifs (frontends, backends). Pas d’accès Internet entrant. Sortie via NAT Service sur le subnet public.
Subnet data — bases de données, caches. Aucun accès Internet (ni entrant, ni sortant). Communication uniquement avec le subnet privé via Security Groups.

Les Security Groups appliquent le pattern SG-to-SG : sg-database autorise le trafic depuis sg-app sur le port 5432, pas depuis un CIDR. Cette indirection permet de remplacer les VMs sans toucher aux règles SG.

L’antipattern fréquent : SSH ouvert sur 0.0.0.0/0. Sur OUTSCALE comme ailleurs, un SSH exposé sur Internet attire en quelques heures des bots de force brute. Le SSH doit transiter par un bastion dans le subnet public, lui-même protégé par un Security Group restrictif (votre IP fixe ou le bloc CIDR de votre VPN).

Chiffrement at-rest

Le chiffrement at-rest se traite différemment selon le service OUTSCALE :

OOS — le chiffrement serveur (SSE) doit être activé explicitement sur le bucket via aws s3api put-bucket-encryption avec une configuration JSON. Une fois activé, tous les nouveaux objets sont chiffrés automatiquement à l’aide d’une clé dérivée de la clé maître du compte. Le chiffrement OOS n’est pas activé par défaut — c’est une décision de configuration côté client.
BSU — la spec OpenAPI ne documente pas de paramètre de chiffrement explicite sur CreateVolume. Pour le niveau de garantie at-rest sur les volumes BSU, consulter la documentation officielle OUTSCALE de la région cible (commerciale eu-west-2 ou souveraine cloudgouv-eu-west-1) car les modèles peuvent différer.

OUTSCALE n’expose pas de service KMS managé natif en 2026 (OKMS est end-of-life). Pour des cas d’usage demandant une gestion fine des clés côté client (rotation contrôlée, destruction prouvable, BYOK applicatif), la pratique consiste à déployer une solution dédiée comme OpenBao (fork open source de HashiCorp Vault) ou HashiCorp Vault sur le compte client, et à chiffrer les données sensibles côté application avant écriture sur le volume ou le bucket. Ce chiffrement applicatif est indépendant du chiffrement infrastructure et complète la posture défense en profondeur.

Chiffrement in-transit

Toutes les communications applicatives doivent utiliser TLS 1.2 minimum (idéalement 1.3). Sur OUTSCALE, les endpoints OAPI sont nativement en TLS — https://api.eu-west-2.outscale.com/api/v1/. Côté workload, les certificats peuvent être gérés via cert-manager sur OKS (avec un issuer Let’s Encrypt ou interne) ou par un script dédié pour les VMs hors Kubernetes.

Surveillance des expirations : tout certificat doit être monitoré via une alerte 30 jours avant expiration. Une expiration imprévue en production reste l’un des incidents les plus fréquents et les plus évitables.

Gestion centralisée des secrets

Les secrets (mots de passe BDD, tokens API, clés privées) ne doivent jamais vivre :

En variables d’environnement dans un docker-compose.yml versionné.
En fichiers .env committés (même dans un .gitignore partiel).
En secrets Kubernetes non chiffrés (par défaut, ils sont seulement encodés base64).

La pratique standard sur OUTSCALE consiste à déployer OpenBao (fork open source de HashiCorp Vault) ou HashiCorp Vault sur un cluster dédié. Le choix du back-end de stockage et du mécanisme d’auto-unseal dépend du contexte opérationnel et doit être documenté dans un ADR (cf. ADR-SEC-02 ci-dessous). Les principes à respecter quel que soit le montage :

Politiques scopées par workload — chaque service ne peut lire que ses propres secrets, principe du moindre privilège appliqué finement.
Authentification des clients par identité forte (service account Kubernetes, AppRole pour les workloads hors cluster, JWT validé côté serveur pour les CI/CD).
Audit log activé sur la solution de secrets, exporté vers un emplacement séparé du compte applicatif.
Plan de rotation appliqué — les secrets dynamiques (BDD, API tiers) sont préférables aux secrets statiques quand la solution le permet.

Journalisation OMS

OMS (OUTSCALE Monitoring Service) enregistre les appels API OUTSCALE — qui, quand, quelle action, sur quelle ressource. L’API associée est ReadApiLogs. Pour le pilier Security, OMS est l’enregistrement de référence en cas d’investigation post-incident.

Point de vigilance important : selon la documentation de l’API, les logs accessibles via ReadApiLogs couvrent les 32 derniers jours par défaut. Pour une rétention longue alignée avec la réglementation (12 à 36 mois selon le secteur), il faut mettre en place un collecteur côté client qui interroge périodiquement l’API et exporte les logs vers un bucket OOS dédié.

Configuration recommandée côté client :

Collecteur de logs planifié (cron, scheduled job, fonction serverless) qui appelle ReadApiLogs et écrit les enregistrements sur un bucket OOS dédié.
Compte d’audit séparé pour héberger le bucket de destination — la séparation organisationnelle protège les logs même en cas de compromission du compte applicatif.
Rétention alignée sur la réglementation applicable (12 mois RGPD courant ; 36 mois SecNumCloud ; vérifier les exigences sectorielles santé/finance).
Exploitation par un SIEM (Splunk, ELK, OpenSearch) ou par des règles d’alerte sur des patterns suspects (création d’access key par un compte non-admin, suppression massive de ressources, modification de politique EIM critique).

Conformité SecNumCloud

La région cloudgouv-eu-west-1 d’OUTSCALE est qualifiée SecNumCloud 3.2 par l’ANSSI. Cette qualification couvre l’infrastructure du fournisseur, pas automatiquement la couche cliente. Pour qu’un workload soit hébergé en conformité SecNumCloud, le client doit appliquer ses propres contrôles : chiffrement, gestion des accès, journalisation, plan de continuité.

Les détails opérationnels et la matrice de responsabilité partagée sont traités dans la page SecNumCloud — implications.

Checklist Definition of Done

Cette checklist doit être validée pour qu’un environnement de production OUTSCALE soit considéré comme conforme Security.

ADR types

ADR-SEC-01 — Rotation systématique des access keys

Contexte : l’organisation utilise des access keys EIM créées il y a plusieurs mois ou années, sans rotation. Le risque de fuite augmente avec le temps (ancien collaborateur, fuite sur un repo privé, dump d’historique).

Décision : appliquer une politique de rotation 90 jours sur toutes les access keys EIM. Implémenter un contrôle hebdomadaire qui liste les access keys via oapi-cli ReadAccessKeys, alerte sur celles dépassant 75 jours, et bloque l’utilisation de celles dépassant 100 jours via une politique EIM dédiée.

Conséquences : effort initial pour outiller la rotation (script de génération + injection dans OpenBao). Bénéfice durable : réduction de la fenêtre d’exploitation d’une clé compromise, conformité avec ISO 27001 / SecNumCloud.

ADR-SEC-02 — Centralisation des secrets sur OpenBao

Contexte : les secrets applicatifs (mots de passe BDD, tokens API tiers, clés privées) sont éparpillés dans des fichiers .env, des secrets Kubernetes en clair, des variables CI. Aucun audit possible.

Décision : déployer OpenBao sur OKS dans un namespace dédié, avec back-end de stockage sur OOS et auto-unseal via un OpenBao transit séparé. Migrer tous les secrets applicatifs vers OpenBao. Imposer aux workloads l’authentification par service account Kubernetes (Kubernetes Auth Method) ou par AppRole (workloads hors Kubernetes).

Conséquences : effort de migration sur 2 à 3 sprints. Bénéfices durables : audit centralisé, rotation possible, principle of least privilege appliqué finement par workload.

Points d’audit correspondants

Sur un compte OUTSCALE réel, ces contrôles peuvent être menés via oapi-cli. Quelques exemples :

oapi-cli ReadAccessKeys

Vérifier l’âge des access keys retournées. Toute clé de plus de 90 jours doit être documentée (justification ADR) ou rotée.

oapi-cli ReadUsers

Lister les utilisateurs EIM. La vérification de la MFA par utilisateur passe par les outils côté Cockpit ou via l’API administrative dédiée — vérifier dans la documentation OUTSCALE de votre région la commande exacte avant tout audit automatisé.

oapi-cli ReadSecurityGroups

Lister les Security Groups et identifier ceux qui autorisent 0.0.0.0/0 sur le port 22 (SSH). Tout résultat doit être documenté ou supprimé.

oapi-cli ReadVolumes

Lister les volumes et inspecter les champs disponibles (VolumeType, Iops, Size, Tags). Pour le chiffrement at-rest, consulter la documentation OUTSCALE du compte cible — il n’est pas exposé sur le schéma Volume de l’OAPI.

L’audit complet est traité dans une page dédiée du Volet 5, à venir.

Antipatterns à éviter

Compte root utilisé au quotidien. Le compte propriétaire (root) ne doit jamais servir aux opérations courantes. Créer un utilisateur EIM admin dédié, désactiver les access keys root, et n’utiliser le root que pour les actions exceptionnelles documentées (changement de plan de facturation, par exemple).

Wildcard EIM *:*. Une politique qui autorise toutes les actions sur toutes les ressources est l’équivalent d’un mot de passe administrateur partagé. Le scoper, même imparfaitement, est toujours mieux que de laisser un wildcard.

Secrets Kubernetes vus comme un coffre-fort. Les secrets Kubernetes par défaut sont encodés en base64, pas chiffrés. Sans EncryptionConfiguration ou sans OpenBao en couche supérieure, ils sont lisibles par toute personne ayant accès au cluster admin.

OMS exporté dans le compte applicatif. Si le compte applicatif est compromis, l’attaquant peut altérer ou effacer les exports. Le collecteur doit écrire vers un compte d’audit séparé, accessible en écriture seule pour le rôle d’export.

TLS désactivé en interne. Considérer que « le réseau interne est de confiance » et désactiver TLS sur les communications inter-services. Une compromission d’un workload donne alors un accès en clair à tout le trafic latéral. Le zero trust demande TLS partout, y compris en interne.

À retenir

EIM disciplinée — MFA partout, rotation 90 jours, scoping fin, pas de root au quotidien.
Segmentation réseau stricte — public / privé / data, pattern SG-to-SG, pas de SSH ouvert.
Chiffrement systématique — BSU et OOS at-rest, TLS 1.2+ in-transit, monitoring certificats.
Secrets centralisés sur OpenBao ou Vault — back-end OOS, auto-unseal, audit log activé.
OMS activé et exploité — export compte audit, object lock, SIEM ou alertes.
Conformité SecNumCloud documentée si applicable — matrice client/fournisseur à jour.

Prochaines étapes

Volet 5 — Vue d'ensemble Le sommaire des 7 piliers Well-Architected appliqués à OUTSCALE.

EIM — identité et accès Le guide complet sur les identités EIM, indispensable au pilier Security.

Réseau — Security Groups La mécanique des SG OUTSCALE et le pattern SG-to-SG.

SecNumCloud — implications Ce que la qualification SecNumCloud 3.2 change concrètement.