Faut-il (tout) backuper (dans) vos tenants Okta?

---

Pourquoi backuper Okta ?

Okta est un IdP (Identity Provider) critique : une perte ou corruption de données peut bloquer tous tes utilisateurs, apps et workflows. Okta garantit le bon fonctionnement de ses services, mais si vous faîtes une erreur et que vous supprimez des données/configurations dans Okta (et ça arrive plus souvent qu’on ne le croit), alors Okta ne propose aucun mécanisme pour permettre à ses clients de restaurer une version antérieure des données présentes dans Okta.

Les principaux risques et enjeux incluent :

• Suppression accidentelle d’un groupe ou d’une application (ex : suppression de "All Employees" → plus personne n’a accès à rien).

• Une automatisation (WorkFlow/Group Rules) qui efface des données sensibles (ex : utilisateurs)

• Corruption d’une politique d’accès (ex : une règle qui bloque tous les accès MFA).

• Attaque malveillante (ex : un admin compromis supprime des utilisateurs ou des apps).

• Migration ou fusion de tenants (ex : acquisition, réorganisation).

• Conformité (ex : DORA, RGPD, SOC2, ISO 27001) exige des sauvegardes pour la reprise d’activité (RTO) et la récupération de données (RPO).

---

Pourquoi ne pas tout backuper ?

Backuper tout dans un tenant Okta n’est généralement ni pertinent, ni nécessaire, ni même toujours possible (mots de passe par exemple*)*.

Une approche sélective, ciblée et structurée est bien plus efficace, sécurisée et maintenable. Ainsi, l’idée générale est de backuper de manière différencielle sur la base des changements d’états d’objets détectés essentiellement via les Logs Okta. Bien entendu, il doit également être possible de faire un full backup mais selon la nature du backup (objets et dépendances) et la taille de la base Okta (Users, Groupes, Group Rules Assignement….), il faudra être prudent afin de permettre un backup dans des temps raisonnables et compatible avec vos opérations (API Rate Limits Okta).

1. Problèmes techniques

   Objet	Problème	Impact
   Utilisateurs	Milliers d’utilisateurs avec des mots de passe hachés (non exportables).	Impossible de restaurer les mots de passe (Okta ne les expose pas).
   Sessions actives	Les sessions en cours ne sont pas backuppables.	Les utilisateurs devront se reconnecter après une restauration.
   Tokens (JWT, etc.)	Les tokens émis ne sont pas sauvegardés.	Invalidation forcée de tous les tokens après restauration.
   Logs/Events	Volume énorme (potentiellement des Go voire des To/mois pour un tenant actif).	Coût de stockage et temps de restauration prohibitifs.
   Intégrations tierces	Certaines apps (ex : AD, Workday..) possède l’autorité de creation/sippression de comptes/attributes/groupes	Une restauration peut casser des syncs ou des mapping d’IDs.
   API Rate Limits	Okta limite les appels API (ex : 10 req/s pour les utilisateurs).	Un backup complet peut prendre des heures/jours et échouer.

2. Problèmes fonctionnels
   - Dépendances complexes : Une Application déclarée dans Okta dépend de :
   1 - Groupes (qui y sont assignés).
   2 - Politiques d'accès ( qui définissent les conditions d'accès )
   3 - Utilisateurs (et leurs attributs).
   4 - Règles de provisioning (sync avec des apps tierces). → Restaurer un seul objet peut casser ces dépendances.
   - Données dynamiques :
   1 - Les mots de passe ne sont jamais exportables (même par Okta Support).
   2 - Les secrets (ex : clés API, certificats) sont masqués dans les exports.
   3 - Les webhooks ou workflows peuvent avoir des états temporaires et l’on sait que le backup des Workflows n’est pas possible par API.
   - Conflits de version: Okta met à jour ses APIs et schémas régulièrement. Un backup ancien peut ne plus être compatible avec la version actuelle du tenant.

3. Problèmes de sécurité et conformité
   - Sensibilité des données : Backuper des PII (Personally Identifiable Information) comme les emails, numéros de téléphone, ou attributs custom peut violer le RGPD ou d’autres réglementations. → Nécessite un chiffrement et un contrôle d’accès strict aux sauvegardes.
   - Exposition des secrets : Même si Okta masque certains secrets dans les exports, des clés API, client secrets (pour OAuth), ou certificats peuvent être inclus dans des configurations. → Risque de fuite de données si la sauvegarde est compromise.
   - Audit et traçabilité : Okta ne journalise pas qui a restauré quoi. Une restauration malencontreuse peut effacer des logs critiques (ex : qui a supprimé un utilisateur ?).

---

Que backuper vraiment ? (Stratégie recommandée)

Approche : Backup sélectif + différenciel + automatisé

Liste des objets à backuper dans la perspective d’un restore

Catégorie	Objets à backuper	Pourquoi ?
Configurations critiques	Politiques d’accès, règles MFA, zones de confiance, paramètres de sécurité, facteurs/authenticateurs.	Ces éléments bloquent/autorisent l’accès à tout le tenant.
Groupes	Tous les groupes Okta (surtout ceux utilisés pour l’accès aux apps).	Les groupes sont au cœur de l’autorisation.
Applications	Métadonnées des apps (SAML/OIDC), assignments de groupes/utilisateurs.	Une suppression d’app = perte d’accès pour des centaines d’utilisateurs.
Utilisateurs	Login, email, nom, groupes, rôles, (custom) attributes…	Une suppression de plusieurs utilisateurs peut survenir notamment quand la MaJ est automatisée
Rôles et permissions	Rôles admin (ex : Super Admin, Org Admin), permissions custom.	Un rôle mal configuré peut donner des accès non autorisés.
Custom Profile	Dans Okta, tous les utilisateurs n’ont pas toujours le même profil	Ces données sont souvent liées à des workflows métiers qui les manipulent
Intégrations	Connecteurs (ex : AD, Workday), mappings d’attributs, attention quand les sources sont autoritaires, on ne peut pas restaurer	Moins critiques, mais à sauvegarder pour une reprise complète.
Branding	Logo, couleurs, emails de bienvenue, etc.	Moins critique, mais utile pour une reprise après incident.