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

**<mark class="bg-yellow-200 dark:bg-yellow-500/30">Les principaux risques et enjeux incluent :</mark>**

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

* * *

### **<mark class="bg-yellow-200 dark:bg-yellow-500/30">Que backuper </mark> *<mark class="bg-yellow-200 dark:bg-yellow-500/30">vraiment</mark>* <mark class="bg-yellow-200 dark:bg-yellow-500/30">? (Stratégie recommandée)</mark>**

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