Sécurité et identité Scaleway : la carte avant de construire

Avant de restreindre quoi que ce soit, il faut savoir qui protège quoi chez Scaleway, et ce que votre organisation applique déjà sans que vous l'ayez décidé. Cette leçon donne la carte du volet Sécurité et identité : les quatre briques (IAM, Secret Manager, Key Manager, Audit Trail) et les réglages d'organisation, ce que chacun protège, ce qui est gratuit, les quotas, et les décisions irréversibles. Vous n'y construirez rien : vous y lirez votre propre organisation avec cinq commandes, et vous en sortirez en sachant par quoi commencer, ce que la leçon suivante mettra en pratique sur une identité de CI.

Ce que vous allez apprendre

• Situer IAM, Secret Manager, Key Manager et Audit Trail, et ce que chacun protège.
• Lire les réglages de sécurité de votre organisation, et savoir lesquels changer en premier.
• Distinguer utilisateur, application et groupe géré, et choisir le bon porteur d'une clé.
• Retrouver une action dans Audit Trail, et savoir quels produits n'y sont pas encore.
• Connaître les quotas, les tarifs et les décisions qui ne se reprennent pas.

Qui protège quoi : les quatre briques

La sécurité Scaleway tient en quatre produits et un jeu de réglages d'organisation, et chacun répond à une question différente. Le tableau se lit par la colonne Question : trouvez celle que vous vous posez, la brique est en face.

Question	Brique	Ce qu'elle fait	Coût
Qui a le droit de faire quoi, où ?	IAM	utilisateurs, applications, groupes, politiques, clés API, conditions	gratuit
Où ranger un mot de passe, un jeton, un certificat ?	Secret Manager	secrets versionnés, typés, chiffrés par enveloppe AES-256, éphémères si besoin	par version stockée et par requête
Comment chiffrer sans jamais voir la clé ?	Key Manager	clés de chiffrement (KEK) qui ne quittent jamais le service, DEK à la demande, signature	0,06 € par version de clé et par mois, 0,03 € par 10 000 requêtes
Qui a fait quoi, quand, depuis où ?	Audit Trail	journal des appels d'API par principal, méthode, statut, adresse source ; export vers Object Storage	gratuit
Comment protéger les comptes eux-mêmes ?	Réglages d'organisation	MFA, expiration des clés, verrouillage, durée de session	gratuit

Glissez pour voir

Une phrase résume le découpage : IAM décide, Secret Manager conserve, Key Manager chiffre, Audit Trail se souvient. Les quatre s'appuient les uns sur les autres : une politique IAM donne accès à un secret, un secret peut contenir une clé API, une clé Key Manager chiffre un bucket, et Audit Trail enregistre chacun de ces accès, à l'exception, au 2 septembre 2026, des produits pas encore intégrés. Le point d'entrée est toujours IAM : sans politique, aucun principal autre que le propriétaire ne lit un secret, n'utilise une clé ni ne consulte le journal. C'est pourquoi ce volet commence par les réglages d'organisation et par une identité restreinte, avant de créer le moindre secret : un coffre bien rempli derrière une porte ouverte ne protège rien.

Que votre organisation applique-t-elle déjà ?

Cinq réglages d'organisation s'appliquent à tous vos membres, et la première manipulation de ce volet consiste à les lire, parce qu'ils décident de ce que la leçon suivante pourra créer. Lancez :

scw iam security-settings get

La sortie doit afficher cinq lignes. Mesuré le 2026-09-08 avec scw 2.56.3 sur l'organisation de test de cette formation :

EnforcePasswordRenewal       true
GracePeriodDuration          3 days
LoginAttemptsBeforeLocked    5
MaxLoginSessionDuration      30 days
MaxAPIKeyExpirationDuration  365 days

Le tableau se lit par la colonne À changer en premier : c'est l'ordre dans lequel un compte neuf gagne le plus de sécurité pour le moins d'effort.

Réglage	Ce qu'il fait	Valeur sur une organisation neuve	À changer en premier
max_api_key_expiration_duration	durée de vie maximale d'une clé API ; 0 = illimité	0	oui : 365 jours au plus, 90 pour les robots ; sans lui, une clé sans échéance sera créée un jour
login_attempts_before_locked	tentatives avant verrouillage du compte	à lire	oui, 5 est un bon défaut
max_login_session_duration	durée maximale d'une session console	à lire	oui, 30 jours ou moins
enforce_password_renewal	renouvellement du mot de passe à la première connexion d'un membre	à lire	oui pour une organisation à plusieurs membres
grace_period_duration	délai laissé à un membre pour se conformer (MFA, mot de passe) avant blocage	à lire	3 jours suffisent

Glissez pour voir

Les cinq se modifient avec scw iam security-settings update (aide de la commande, 2.56.3). Le premier est celui qui compte : la leçon suivante montre que, quand il est posé, la création d'une clé sans expires-at échoue sur organization security settings require an expiration date for API keys, et que c'est une bonne nouvelle.

Humain, robot ou groupe : qui porte les droits ?

IAM connaît trois sortes de principals, et une politique n'en accepte qu'un seul : choisir le bon porteur est la décision qui structure toute l'organisation. Le tableau se lit par la colonne Choix.

Besoin	Choix	Pourquoi
Une personne qui se connecte à la console	utilisateur (Owner ou membre)	mot de passe, MFA, sessions ; ses clés API portent ses droits
Une CI, un script, Terraform, un agent	application	aucun accès console, n'existe que par sa clé API, survit aux départs
Un droit partagé par plusieurs personnes ou robots	groupe	la politique s'écrit une fois, on gère les entrées et sorties
Un droit pour tous les humains, ou tous les robots	groupes gérés All Users et All Applications	créés par Scaleway le 2 septembre 2026, à membres dynamiques : commodes, et à portée large par construction
Provisionner les membres depuis un annuaire	SCIM (Entra ID, Authentik)	groupes SCIM depuis le 18 août 2026, fédération d'identité SSO

Glissez pour voir

Regardez ce que votre organisation contient déjà :

scw iam group list
scw iam policy list

Sur l'organisation de test, relevé du 2026-09-08 : 5 groupes (All Users, All Applications, Billing Administrators, Administrators, Editors) et 3 politiques créées par Scaleway (Administrators, Editors, Billing Administrators), chacune attachée à son groupe. Ce ne sont pas des restes de lab : ce sont les rôles par défaut, et la question à se poser est qui est dans le groupe Administrators, parce que tout membre qu'on y ajoute reçoit tous les droits.

Le vocabulaire des droits est un catalogue de jeux de permissions, InstancesFullAccess, BillingReadOnly, KeyManagerKeyDecrypt. Relevé le 2026-09-08 : 179 jeux (scw iam permission-set list), dont douze pour Key Manager, sept pour Secret Manager, onze pour Audit Trail et neuf pour l'Object Storage. Leur nom se lit seul, et c'est ce qui rend l'ensemble utilisable sans documentation.

Les conditions : restreindre par requête ou par ressource

Depuis le 15 juillet 2026, une politique peut porter des conditions au niveau de la ressource, et depuis plus longtemps au niveau de la requête ; c'est ce qui rend le moindre privilège enseignable. Les conditions s'écrivent en CEL (Common Expression Language). Deux familles existent :

• Au niveau de la requête : l'adresse IP publique d'origine (request.ip), l'agent utilisateur (request.user_agent.contains("terraform/")), ou l'heure (request.time). Un exemple qui limite aux jours ouvrés, 8 h à 17 h, heure de Paris : request.time.getDayOfWeek() != 0 && request.time.getDayOfWeek() != 6 && request.time.getHours("Europe/Paris") > 8 && request.time.getHours("Europe/Paris") < 17. Dans CEL, getDayOfWeek() vaut 0 le dimanche et 6 le samedi ; une condition « week-end » s'écrit donc avec == 0 || == 6, ce que la page officielle présente à l'envers au 8 septembre 2026, écart signalé au dépôt de documentation.
• Au niveau de la ressource : par clé, par secret (resource.name.startsWith("/dossier/")), par utilisateur ou politique. Au 13 juillet 2026, trois produits sont intégrés : IAM, Key Manager (par clé, pas par version) et Secret Manager (par secret, pas par version).

Une politique ne peut qu'accorder : il n'existe pas de règle « interdire ». Le point de départ de tout principal autre que le propriétaire est zéro droit, et les politiques s'additionnent sans priorité ; une nouvelle configuration peut mettre jusqu'à une minute à s'appliquer.

Secret Manager ou Key Manager : où va quoi ?

Secret Manager conserve des valeurs, Key Manager conserve des clés qui ne sortent jamais ; confondre les deux mène soit à stocker une clé de chiffrement comme un simple secret, soit à chercher dans Key Manager un mot de passe qui n'y sera jamais. Le tableau se lit par la colonne Choix.

Ce que vous avez	Choix	Pourquoi
Mot de passe de base, jeton d'API, certificat, clé SSH, JSON de configuration	Secret Manager	versions immuables, 6 types de secrets, 64 Ko au plus, lecture par l'API avec une politique IAM
Un secret qui ne doit servir qu'une fois, ou expirer sous un an	Secret Manager, avec une politique éphémère	accès unique ou durée de vie ; posée à la création, jamais retirable ensuite
Chiffrer des données volumineuses dans votre application	Key Manager, chiffrement par enveloppe	une DEK générée à la demande chiffre les données ; la KEK qui la protège ne quitte jamais le service
Chiffrer un bucket Object Storage avec une clé à vous	Key Manager via SSE-KMS	intégration disponible depuis le 3 juin 2026
Signer et vérifier des documents	Key Manager, usage asymmetric_signing	signature par clé privée, vérification par clé publique
Protéger un chiffrement asymétrique contre le quantique	Key Manager, usage asymmetric-encryption, ML-KEM	ml_kem_768 ou ml_kem_1024, mécanisme d'encapsulation de clé FIPS 203
Protéger une signature contre le quantique	Key Manager, usage asymmetric-signing, ML-DSA	ml_dsa_44, ml_dsa_65 ou ml_dsa_87, schéma de signature FIPS 204
La clé API d'un robot	IAM, portée par une application	et sa valeur, si un autre système doit la lire, dans Secret Manager

Glissez pour voir

Post-quantique : deux familles, deux menaces

Il n'y a pas « un » algorithme post-quantique, il y en a deux familles, et elles ne protègent pas la même chose. La confusion est fréquente, y compris dans des supports sérieux, parce que les deux noms se ressemblent.

ML-KEM (Module-Lattice Key Encapsulation Mechanism, FIPS 203) est un mécanisme d'encapsulation de clé : il protège la mise en place d'un secret partagé. Il répond à la menace dite « récolter maintenant, déchiffrer plus tard », où un attaquant enregistre aujourd'hui du trafic chiffré pour le casser quand un ordinateur quantique existera.

ML-DSA (Module-Lattice Digital Signature Algorithm, FIPS 204) est un schéma de signature. Il ne protège aucune confidentialité : il garantit qu'un message vient bien de qui il prétend, y compris contre un futur attaquant quantique.

Le suffixe numérique désigne la catégorie de sécurité, pas une taille de clé : ml_kem_768 relève de la catégorie 3, ml_kem_1024 de la catégorie 5.

Ces valeurs se lisent directement dans l'aide du CLI, ce qui est le meilleur moyen de vérifier ce que votre version propose réellement :

scw keymanager key create -h

La sortie doit énumérer, pour usage.asymmetric-encryption, les valeurs ml_kem_768 et ml_kem_1024 aux côtés des variantes RSA-OAEP, et pour usage.asymmetric-signing, les trois variantes ml_dsa_44, ml_dsa_65 et ml_dsa_87. Relevé le 10 septembre 2026 avec scw 2.62.0.

Deux propriétés méritent d'être sues avant le premier secret. Dans Secret Manager, les secrets sont régionaux (Paris, Amsterdam, Varsovie), répliqués sur les zones de la région, chiffrés par enveloppe AES-256 ; un secret marqué protégé ne peut plus être supprimé, mais ses versions le peuvent ; et deux suppressions coexistent, qu'il ne faut pas confondre. scw secret secret delete supprime immédiatement : mesuré le 10 septembre 2026 avec scw 2.62.0, la commande répond « Secret has been successfully deleted. » et le secret quitte la liste dans la seconde. La suppression programmée est un mécanisme distinct, qui place le secret dans une fenêtre de 7 jours pendant laquelle il reste lisible mais ni modifiable ni accessible, et pendant laquelle une récupération est facturée 0,01 € par version. Dans Key Manager, la KEK est permanente et ne se lit jamais ; une rotation ne remplace que les opérations futures, tout ce qui a été chiffré avec une version précédente reste déchiffrable ; la rotation n'existe que pour les clés symétriques (AES_256_GCM), conseillée tous 30 à 90 jours ; et la suppression est elle aussi différée de 7 jours.

Regardez ce que votre projet contient, vous devriez voir deux listes vides sur un compte neuf :

scw secret secret list region=fr-par
scw keymanager key list region=fr-par

Chaque commande doit renvoyer [] ou un tableau vide. Si ce n'est pas le cas, un secret ou une clé existe déjà dans ce projet, et c'est le moment de savoir qui l'a créé : Audit Trail répond à cette question.

Audit Trail : qui a fait quoi, et depuis où ?

Audit Trail enregistre chaque appel d'API sur votre organisation, réussi ou refusé, avec le principal, la méthode, le statut, l'adresse source et l'agent utilisateur ; il est gratuit, et sa lecture est la troisième manipulation de cette leçon.

scw audit-trail event list region=fr-par -o json \
  | python3 -c 'import sys,json; [print(e["recorded_at"][:19], e["product_name"], e["method_name"], e["status_code"], e["source_ip"]) for e in json.load(sys.stdin)]'

La sortie doit afficher une ligne par événement de la dernière heure (valeur par défaut de recorded-after). Mesuré le 2026-09-08, juste après le lab IAM de la leçon suivante : les événements DeleteSecurityGroup (statut 204, produit instance, localité fr-par-1) et DeleteApplication (statut 200, produit iam, localité global) apparaissent avec l'adresse IP d'origine et l'agent scaleway-cli/2.56.3. Un appel refusé y figure avec le statut 403 : c'est ainsi qu'on voit une clé restreinte tenter ce qu'elle ne peut pas faire.

Les filtres de la commande (resource-type, method-name, status, principal-id, source-ip, recorded-after) permettent de répondre à des questions précises : qui a créé cette clé API, depuis quelle adresse une application a-t-elle été refusée, quels appels ont eu lieu sur ce projet la nuit dernière. Trois limites à connaître (FAQ et page d'intégration, validées le 30 juillet et le 2 septembre 2026) :

• Les événements sont stockés dans la région de l'action ; les produits globaux (IAM, Account, Edge Services) sont rangés à Paris. L'aide de scw audit-trail event list n'énumère que fr-par et nl-ams en 2.56.3 comme en 2.62.0, alors que la doc cite aussi Varsovie et Milan.
• L'export vers un bucket Object Storage conserve les événements des 90 derniers jours, un export par région, tous les événements ; il tourne chaque jour et alimente prefix/AAAA/MM/JJ/logs_….json. Une intégration Splunk native existe depuis le 6 août 2026.
• Tous les produits n'y sont pas : Instances, VPC, IAM, Kubernetes, bases PostgreSQL et MySQL, Secret Manager, Key Manager, Load Balancer et Public Gateway le sont ; Object Storage, Block Storage, Billing, Container Registry et Domains ne le sont pas encore au 2 septembre 2026. Un accès à un bucket ne se retrouve donc pas dans Audit Trail.

Quelles décisions ne se reprennent pas ?

Cinq décisions de ce volet sont irréversibles ou coûteuses à défaire. Le tableau se lit par la colonne Pourquoi.

Décision	Quand la prendre	Pourquoi elle ne se reprend pas
Créer une clé API sur un utilisateur plutôt qu'une application	à chaque robot	la clé porte tous les droits de la personne et lui survit ; la corriger impose de recréer la clé partout où elle est déployée
Poser une politique éphémère sur un secret	à la création	elle ne peut jamais être retirée ; le secret expire ou s'autodétruit comme prévu
Choisir le mode Compliance d'un Object Lock	au verrouillage	personne, pas même vous, ne peut supprimer l'objet avant l'échéance
Ajouter un membre au groupe Administrators	jamais par défaut	il reçoit tous les droits, y compris IAM, donc la capacité de se maintenir
Supprimer une clé Key Manager	après un délai de 7 jours	passé ce délai, tout ce qui a été chiffré avec elle est perdu

Glissez pour voir

Ce que Scaleway sécurise, et ce qui vous revient

Le modèle de responsabilité partagée place la frontière au niveau de ce que vous configurez : Scaleway sécurise la plateforme, vous sécurisez ce que vous y déposez, et cette leçon vous donne les outils de votre côté. Concrètement, Scaleway fait tourner IAM, chiffre les secrets au repos, garde les KEK dans ses installations avec une clé racine par région, et n'a aucun accès à un serveur Elastic Metal une fois installé. De votre côté : les politiques, l'expiration des clés, la MFA des humains, la rotation des clés de chiffrement, la sauvegarde des données, et la lecture d'Audit Trail. La page Responsabilité partagée cloud détaille ce partage pour les cinq modèles de service.

Deux protections des comptes humains complètent la carte (page « Account concepts », validée le 3 septembre 2025). L'authentification multifacteur existe en TOTP pour tous, et en passkey WebAuthn depuis le 31 juillet 2026, réservée pour l'instant aux propriétaires d'organisation ; un membre soumis à une exigence de MFA dispose du délai de grâce de l'organisation avant blocage. Et la page Sessions actives de la console liste les appareils connectés, chacun porté par un jeton JWT que l'on peut révoquer.

Limites, quotas et plafonds

Ces valeurs viennent de la page des quotas d'Organisation (validée le 2025-10-29), des FAQ IAM, Secret Manager, Key Manager et Audit Trail, et du relevé du 2026-09-08.

Plafond	Valeur	Source
Clés API par Organisation	50 (page des quotas) ; la FAQ IAM dit 100, écart signalé	quotas, FAQ IAM
Applications, groupes, politiques, utilisateurs	100, 50, 50, 50	quotas d'Organisation
Principal par politique	1 ; règle « accorder » seulement, pas de règle « interdire »	doc « Understanding IAM policies »
Délai d'application d'une politique	jusqu'à 1 minute	doc « Understanding IAM policies »
Jeux de permissions	179 au 2026-09-08	scw iam permission-set list
Durée maximale d'une clé API	réglable ; 365 jours sur l'organisation de test, 0 = illimité par défaut	scw iam security-settings get
Taille d'un secret	64 Ko ; 6 types ; régions fr-par, nl-ams, pl-waw	FAQ et concepts Secret Manager
Suppression différée	7 jours pour un secret comme pour une clé ; récupération 0,01 € par version ou par clé	concepts Secret Manager, FAQ Key Manager
Tarif Key Manager	0,06 € par version de clé et par mois, 0,03 € par 10 000 requêtes	FAQ Key Manager
Rotation conseillée	tous les 30 à 90 jours, clés symétriques seulement	concepts Key Manager
Rétention exportable d'Audit Trail	90 jours, un export par région	concepts Audit Trail
Produits hors Audit Trail au 2026-09-02	Object Storage, Block Storage, Billing, Container Registry, Domains, GPU	page d'intégration Audit Trail

Glissez pour voir

Antipatterns à éviter

Ces erreurs ne déclenchent aucune alerte : IAM accepte une clé éternelle, un groupe Administrators pléthorique et une politique de portée Organization sans broncher.

Antipattern	Conséquence	Discipline
Laisser max_api_key_expiration_duration à 0	des clés sans échéance finissent par exister, et personne ne les tourne	365 jours au plus, dès le premier jour
Une clé API personnelle dans une CI	la CI porte facturation et IAM, et survit au départ de la personne	une application par robot, une politique par projet
Donner IAMManager ou AllProductsFullAccess à une identité de déploiement	elle peut se réécrire ses droits ; la restriction ne vaut rien	jamais de permission IAM sur un robot de déploiement
Utiliser All Users pour un droit sensible	tout nouveau membre l'obtient automatiquement	groupes nommés à membres explicites pour tout ce qui dépasse la lecture
Stocker une clé de chiffrement dans Secret Manager	la clé se lit, se copie, se perd	Key Manager, dont la KEK ne sort jamais
Compter sur Audit Trail pour les accès aux buckets	non intégré au 2 septembre 2026 : rien n'est enregistré	journaux Cockpit du bucket, politique de bucket avec TLS imposé

Glissez pour voir

La sécurité Scaleway sous l'angle Well-Architected

Security : zéro droit par défaut, et le prouver

Que peut faire ce principal, exactement ? Ce que ses politiques accordent, rien de plus, à partir de zéro. La discipline est une application par robot, une politique limitée à un projet et à quelques jeux, une condition de requête quand l'origine est connue, et une preuve par écriture refusée, parce qu'une lecture hors périmètre renvoie une liste vide, pas une erreur. La leçon suivante le mesure.

Operational Excellence : lisible dans six mois

Quelqu'un qui reprend votre organisation comprendra-t-il qui a accès à quoi ? Oui, si chaque application porte le nom de son usage, si les groupes ont des noms qui disent leur rôle, et si Audit Trail est exporté vers un bucket avec cycle de vie. La discipline est une revue trimestrielle des clés (échéance, dernière utilisation), des groupes et des politiques, et un export Audit Trail configuré avant le premier incident.

Cost Optimization : trois briques gratuites, deux facturées à l'unité

Combien coûte la sécurité ? IAM et Audit Trail, rien ; Secret Manager, par version et par requête ; Key Manager, 0,06 € par version de clé et par mois. La discipline est de ne pas créer une version de secret à chaque déploiement quand la valeur n'a pas changé, et de supprimer les versions inutiles, puisque chacune se facture, activée ou non.

Pièges courants

Le tableau se lit par la colonne Symptôme : c'est ce que vous voyez à l'écran, message exact compris quand il y en a un ; la colonne Cause dit ce qui se passe réellement, et la colonne Solution la commande ou le geste qui débloque.

Symptôme	Cause	Solution
organization security settings require an expiration date for API keys	l'organisation impose une durée de vie maximale	ajouter expires-at=<date ISO 8601> ; c'est le comportement souhaité
insufficient permissions: create compute_security_groups	la politique de l'identité ne couvre pas ce projet ou ce produit	relire scw iam rule list policy-id=… ; c'est la preuve qu'une restriction tient
Une lecture hors périmètre renvoie []	les ressources hors portée sont filtrées en silence	vérifier une restriction par une écriture, jamais par une lecture
Un nouveau membre a accès à tout	il a été ajouté au groupe Administrators, ou All Users porte une politique large	groupes nommés, politique par projet
Un secret « supprimé » est toujours facturé	suppression différée de 7 jours	attendre le délai, ou vérifier que la suppression a bien été planifiée
Aucun événement Audit Trail pour un accès à un bucket	Object Storage non intégré au 2 septembre 2026	journaux Cockpit du bucket
scw audit-trail event list region=pl-waw refusé par l'aide du CLI	énumération limitée à fr-par et nl-ams dans le binaire	mettre à jour la CLI, ou lire la région depuis la console

Glissez pour voir

Contrôle de connaissances

Vérifiez que l'essentiel de ce guide est acquis. Les questions portent uniquement sur ce qui vient d'être expliqué ici.

Contrôle de connaissances

Validez vos connaissances avec ce quiz interactif

6 questions

6 min.

70% requis

Informations

• Le chronomètre démarre au clic sur Démarrer
• Questions à choix multiples, vrai/faux et réponses courtes
• Vous pouvez naviguer entre les questions
• Les résultats détaillés sont affichés à la fin

Démarrer le quiz

Lance le quiz et démarre le chronomètre

À retenir

• IAM décide, Secret Manager conserve, Key Manager chiffre, Audit Trail se souvient ; IAM et Audit Trail sont gratuits, Secret Manager se facture par version et requête, Key Manager 0,06 € par version de clé et par mois.
• scw iam security-settings get lit les cinq réglages d'organisation ; le premier à poser est max_api_key_expiration_duration, 0 par défaut, 365 jours sur l'organisation de test.
• Trois principals, utilisateur, application, groupe, plus les groupes gérés All Users et All Applications (2 septembre 2026) ; une politique n'a qu'un principal et ne fait qu'accorder.
• 179 jeux de permissions au 2026-09-08 ; conditions de requête (IP, agent, heure) et, depuis le 15 juillet 2026, conditions au niveau de la ressource pour IAM, Key Manager et Secret Manager.
• Dans CEL, getDayOfWeek() vaut 0 le dimanche et 6 le samedi ; l'exemple « week-end » de la doc officielle est inversé au 8 septembre 2026.
• Secret Manager : 65 535 octets au plus par version, 6 types, régional, politique éphémère irrévocable, suppression immédiate par défaut et fenêtre de 7 jours seulement en suppression programmée ; Key Manager : KEK qui ne sort jamais, rotation symétrique tous les 30 à 90 jours, et deux familles post-quantiques à ne pas confondre, ML-KEM pour l'encapsulation de clé et ML-DSA pour la signature.
• Audit Trail : scw audit-trail event list montre principal, méthode, statut (200, 204, 403), adresse source ; export 90 jours vers Object Storage ; Object Storage, Block Storage et Billing pas encore intégrés.
• MFA en TOTP pour tous, passkeys pour les propriétaires depuis le 31 juillet 2026 ; SCIM depuis le 18 août 2026.

Pour aller plus loin

• Ansible : exploiter ce que Terraform a provisionné : L'identité d'application créée ici devient la clé que pilote un playbook, et la leçon montre où cette clé se lit.

Ressources externes

Les pages officielles sur lesquelles cette leçon s'appuie, avec ce qu'on y cherche ; leur champ de validation date chaque fait cité.

• IAM concepts : principal, application, groupe, politique, règle, portée, condition, période de grâce.
• Understanding IAM policies : un principal par politique, règles qui accordent seulement, délai d'application.
• Request-level conditions et Products supporting resource-level conditions : les variables CEL et les produits intégrés.
• Secret Manager concepts et Key Manager concepts : versions, politiques éphémères, KEK, DEK, rotation, suppression différée.
• Audit Trail product integration : la liste des produits intégrés et de ceux qui ne le sont pas encore.
• Account concepts : MFA, passkeys, SSO, sessions actives.

×

📖 Voir la documentation →