Au-delà des frontières du cloud : construire une infrastructure résiliente dans des environnements hybrides et SaaS

Résumé

L’Enterprise moderne repose sur une infrastructure cloud. L’adoption rapide des plateformes de Software-as-a-Service (SaaS) et d’infrastructure en tant que service (IaaS) a renforcé l’agilité des entreprises, réduit les dépenses d’investissement et permis d’atteindre une échelle opérationnelle inédite. 

Cependant, cette dépendance totale aux systèmes hébergés dans le cloud a fait émerger un paradoxe majeur : en déplaçant leur infrastructure essentielle hors de leurs frontières physiques et administratives, les organisations ont créé des dépendances profondes et systémiques vis-à-vis de réseaux externes et de prestataires tiers.

Lorsque ces dépendances sont défaillantes, en raison de coupures physiques de fibre, de mauvaises configurations de routage, de défaillances du Domaine Name System (DNS) ou de pannes régionales chez les principaux hyperscalers, les opérations modernes s’arrêtent immédiatement. Pour les secteurs essentiels tels que la santé, la défense, l’industrie, les services publics, la finance, le commerce de détail et les transports, une perte de connectivité au cloud ne constitue pas simplement un désagrément technique, mais représente une menace pour la sécurité des personnes, la sécurité nationale et la stabilité économique.

La planification de la continuité d’activité (BCP) à l’ère du cloud first exige une préparation supplémentaire. En examinant les méthodologies traditionnelles de PCA, en explorant les cadres modernes d’edge computing tels qu’AWS Outposts et en démontrant la résilience centrée sur l’identité grâce aux fonctionnalités hors ligne du service d’authentification locale Okta, nous montrons que la résilience locale n’est plus un luxe. Il s’agit d’une stratégie essentielle pour l’Enterprise moderne.

Comment le cloud redéfinit-il la planification de la continuité de l’activité ?

Pendant des décennies, le paradigme standard de l’IT imposait que la résilience passait par la duplication de l’infrastructure physique : création de data centers secondaires, provisionner des alimentations redondantes et recours à la séparation géographique. La transition vers le cloud a transféré cette charge aux fournisseurs de services cloud (CSP). De nombreux cadres dirigeants ont cru à tort que l’adoption du cloud était synonyme de disponibilité garantie. 

Quels sont les risques liés au fait de s’appuyer uniquement sur une infrastructure cloud ?

Alors que les principaux fournisseurs de cloud et de SaaS investissent des milliards de dollars dans le basculement multi-région et des architectures à haute disponibilité, ils restent exposés à des points de défailllance uniques. Une seule route Border Gateway Protocol (BGP) mal configurée, une défailllance de résolution DNS ou une erreur en cascade d’API dans une région principale d’un hyperscaler peut instantanément priver des milliers d’organisations de leurs systèmes essentiels.  

Cette vulnérabilité n’est pas entièrement numérique. Un seul conducteur de pelleteuse coupant une ligne de fibre optique souterraine lors de travaux de voirie courants, ou un acte de sabotage physique ciblé, peut instantanément priver une entreprise de son accès vital au cloud, rendant ainsi des ressources distantes pourtant opérationnelles totalement inaccessibles. 

Dans ces situations, le fournisseur cloud peut fonctionner normalement en interne, mais si le réseau de l’Enterprise ne parvient pas à accéder aux terminaux du fournisseur, le service est en pratique indisponible.

Quels principes fondamentaux de sécurité s’appliquent à la conception de réseaux résilients ?

Pour répondre à ces risques, la planification de la continuité doit intégrer les principes fondamentaux de la sécurité de l’information et de la reprise après incident :

Cartographier l’essentiel : l’état des lieux

Avant de pouvoir corriger quoi que ce soit, vous devez savoir ce que vous protégez réellement. Cela signifie identifier les éléments absolument essentiels de votre activité qui ne peuvent pas être interrompus, puis remonter jusqu’à chaque fournisseur cloud ou outil SaaS sur lesquels ils reposent. Si vous ne savez pas où se trouvent vos dépendances, vous ne pouvez pas les protéger.

L’équation de la survie : pourquoi le calcul ne tient pas

Dans le domaine de la sécurité, une règle fondamentale conditionne la pérennité des entreprises : votre durée maximale d’interruption admissible (MTD), c’est-à-dire la limite absolue pendant laquelle votre entreprise peut survivre tout en subissant des pertes financières, doit être supérieure au temps nécessaire pour résoudre le problème technique (appelé Recovery Time Objective ou RTO), auquel s’ajoute le temps requis pour permettre à vos données et à vos équipes de reprendre une activité normale (WRT) :

 MTD >= RTO + WRT

Voici le point sensible avec le cloud : si vous perdez totalement la connexion, votre RTO peut devenir indéterminé, car rétablir la connectivité peut ne pas dépendre de vous. Si vous ne disposez pas d’une solution hors ligne, cette équation ne tient plus du tout et l’entreprise se retrouve à court de temps.

Dégradation progressive : « mode îlot » 

Si une Enterprise perd sa connexion avec l’extérieur, elle doit pouvoir continuer à fonctionner de manière autonome, devenant ainsi une « île » opérationnelle. Le réseau local doit assurer le Support des tâches essentielles, vitales ou génératrices de revenus à capacité réduite, sans dépendre d’échanges avec le cloud externe.

Quel est l’impact des interruptions de services cloud sur les secteurs critiques ?

Les différents secteurs et entreprises fonctionnent de manière très différente, mais le besoin de résilience lors de l’utilisation du cloud concerne de nombreux secteurs. Vous trouverez ci-dessous une cartographie détaillée de l’impact des interruptions de services cloud sur certains secteurs essentiels, mettant en évidence les domaines où la continuité opérationnelle locale est indispensable :

Comment les interruptions de connexion au cloud mettent en péril la continuité de l’activité

Vulnérabilités propres au secteur

Santé et opérations cliniques

Dans les hôpitaux, l’accès immédiat aux dossiers médicaux électroniques, à la télémétrie patient en temps réel et aux armoires automatisées de distribution de médicaments relève d’enjeux vitaux. Si la connexion à un DSE hébergé dans le cloud est interrompue, les professionnels de santé perdent l’accès aux antécédents médicaux essentiels, aux allergies et aux traitements en cours. Les workflows sont ralentis, entraînant une compromission directe de la sécurité des patient·es.

Défense militaire et tactique

Les forces armées opèrent régulièrement dans des environnements où la connectivité est refusée, dégradée, intermittente ou limitée (DDIL). Les centres de commandement, les réseaux de communication et les systèmes logistiques tactiques doivent fonctionner de manière fiable sans connexion permanente à un cloud central. Dans les architectures de défense, une dépendance forte à des services cloud externes constitue une vulnérabilité majeure pour la sécurité nationale.

Services publics et infrastructures critiques

Les réseaux électriques, les systèmes de traitement de l’eau et les pipelines de transport d’énergie reposent sur des systèmes de contrôle et d’acquisition de données (SCADA). Ces systèmes de contrôle industriel doivent surveiller et ajuster l’infrastructure physique localement. Si la couche de surveillance connectée au cloud tombe, les systèmes localisés doivent conserver un contrôle autonome et sécurisé afin d’éviter des défaillances systémiques majeures.

Industrie manufacturière et automatisation industrielle

Les usines intelligentes modernes reposent sur des réseaux IoT industriels à haut débit et des systèmes d’assemblage automatisés. Même une brève interruption du réseau peut désynchroniser les robots, bloquer les chaînes de production et entraîner un gaspillage important. Les interruptions imprévues dans l’industrie manufacturière lourde coûtent plusieurs dizaines de milliers de dollars par minute, ce qui impose aux contrôleurs locaux Edge de fonctionner sans validation à distance.

Logistique du transport et de l’expédition

Les ports, les hubs et les compagnies maritimes internationales ne peuvent pas se permettre de subir des goulets d’étranglement logistiques. Si les services cloud régionaux deviennent indisponibles, les véhicules autonomes guidés (AGV) doivent continuer à se déplacer en toute sécurité, la lecture des manifestes doit se poursuivre et les systèmes d’acheminement des conteneurs doivent mettre les transactions en file d’attente localement, puis les synchroniser de manière asynchrone lorsque la liaison WAN est rétablie.

Pourquoi l’identité constitue-t-elle le principal point de contrôle en matière de sécurité ?

Dans les architectures Zero Trust modernes, l’identité constitue le principal point de contrôle de la sécurité. Une entreprise peut déployer des applications on-premise hautement résilientes. Cependant, si ces applications dépendent d’un fournisseur d’identité cloud (IdP) inaccessible pour l’authentification des utilisateurs, elles deviennent inutilisables en cas de déconnexion.

Pourquoi les flux de redirection standard échouent-ils lors des pannes du cloud ?

Dans un déploiement d’identité typique dans le cloud, l’authentification unique (SSO) utilisant Security Assertion Markup Language (SAML) ou OpenID Connect (OIDC) repose sur la redirection du navigateur de l’utilisateur entre l’application et Okta. En cas d’interruption d’accès à Internet ou à une solution SaaS :

• L’application ne peut pas valider les assertions d’identité entrantes.
• Le navigateur de l’utilisateur ne parvient pas à résoudre ou à atteindre les terminaux d’authentification cloud.
• Les vérifications de token en canal secondaire échouent.

Pour survivre, le réseau de l'Enterprise doit revenir en « mode îlot », en s’appuyant à nouveau sur des annuaires locaux et des serveurs d’identité locaux capables de délivrer des tokens valides de manière native en Edge. Ceci est important aussi bien pour les applications web traditionnelles que pour l’IA agentique, où l’agent peut être on-premise et doit accéder à des ressources on-premise.

Comment le service d’authentification locale Okta maintient-il sa disponibilité ?

Pour résoudre le goulet d'étranglement lié à la pérennité de l'identité, Okta a développé le service d’authentification locale Okta, intégré à l’ Okta Access Gateway (OAG). OAG est une gateway appliance localisée, déployée en on-premise ou dans un cloud hybride. 

Dans cette architecture, OAG n’est pas un simple reverse proxy qui filtre, authentifie et transmet le trafic aux applications ; il agit plutôt comme l’IdP principal pour les applications d’entreprise locales utilisant SAML et OIDC.

Comment Okta Access Gateway maintient l’authentification locale en cas d’incident

Les mécanismes de transition hors ligne

1. Surveillance continue de l’état de santé : OAG surveille en permanence l’état de la connexion au tenant Okta Cloud en amont grâce à des intervalles de contrôle d’intégrité configurables.
2. Détection des interruptions : si l’échec de connexion dépasse le seuil de basculement configuré, OAG bascule automatiquement les applications cibles en mode Authentification déconnectée.
3. Vérification locale des identifiants : Au lieu de rediriger l’utilisateur vers le tenant Okta Cloud, OAG affiche une page de connexion personnalisée et localisée, accessible hors ligne. Les utilisateurs saisissent leurs identifiants, que OAG valide directement auprès d’un service d’annuaire local tel qu’Active Directory (AD) ou Lightweight Directory Access Protocol (LDAP), synchronisé avec le cloud via l’agent Okta AD/LDAP.
4. Application locale des politiques : OAG évalue les politiques d’authentification locales en mode déconnecté afin de garantir que seuls les groupes d’utilisateurs autorisés obtiennent l’accès aux applications critiques pendant les périodes de « break-glass ».
5. Génération locale de token : OAG signe et émet de manière cryptographique des tokens SAML ou OIDC directement depuis l’appliance locale vers l’application, tout en maintenant un accès ininterrompu à la session.
   

Quelles sont les limites des architectures hybrides en Edge ?

Pour limiter l’impact des interruptions du WAN et des fournisseurs cloud, atteindre une véritable résilience opérationnelle nécessite une stratégie multiniveau. Alors qu’Okta concentre ses efforts sur le renforcement du point de contrôle de l’identité, l’infrastructure sous-jacente doit évoluer en parallèle, ce qui conduit les Enterprise à adopter de plus en plus une topologie hybride Edge, prolongeant ainsi l’infrastructure cloud jusque dans les sites physiques locaux. 

Un exemple clé de ce modèle est AWS Outposts, une solution hybride entièrement gérée qui propose des services AWS natifs, des API et des outils de sécurité directement dans l’environnement on-premise du client.

Caractéristiques de résilience des AWS Outposts

Dans des conditions d’exploitation normales, AWS Outposts se connecte à une région AWS principale via un lien WAN actif ou AWS Direct Connect. Cependant, lorsque les connexions réseau locales se dégradent, Outposts présente les comportements architecturaux suivants :

Continuité d’exécution locale : Les applications déjà en cours d’exécution sur la baie Outpost continuent de fonctionner localement. Elles restent accessibles par les appareils clients locaux.

• Latence inférieure à 10 ms : Les systèmes localisés interagissent avec l’infrastructure Outpost avec une latence de quelques millisecondes seulement, contournant ainsi la pénalité habituelle de routage dans le cloud de 30 à 100 ms.

Parcours des données locales : Le trafic destiné aux bases de données locales ou aux systèmes hérités on-premise transite entièrement par la LGW, ce qui évite toute exposition aux vulnérabilités du WAN.

Limitations d’Edge 

Bien qu’AWS Outposts constitue une avancée pour les déploiements hybrides, il met en évidence une limite fondamentale du cloud hybride : il n’est pas conçu pour des opérations permanentes, isolées et hors ligne.

• Point de contrôle API dégradé : En cas de déconnexion, les actions administratives locales sont fortement limitées. Les appels d’API visant à exécuter, démarrer, arrêter ou mettre fin à des instances échouent, car le point de contrôle se trouve dans la région AWS parente.
• Limites de mise en cache des journaux et des métriques : Les métriques CloudWatch et les journaux système sont mis en cache localement sur le rack Outpost en cas d’incident. Cependant, ce cache est limité à sept jours. Si la connectivité n’est pas rétablie dans ce délai, les journaux d’audit critiques, les indicateurs de sécurité et les métriques de santé sont définitivement perdus.

Cela met en évidence une réalité essentielle de l’ingénierie : pour garantir la continuité de l’activité, les organisations ne peuvent pas simplement compter sur l’hébergement de leur infrastructure Edge. Ils doivent également disposer d’un point de contrôle d’identité résilient, capable de fonctionner en Edge, afin d’authentifier et d’autoriser les utilisateurs sur ces systèmes locaux. 

Okta Access Gateway, déployé au sein d’une infrastructure AWS Outpost, peut offrir une authentification hors ligne et une gestion de l’identité en Edge pour les infrastructures critiques en cas d’interruption du WAN.

Comment configurer des politiques d’authentification hors ligne ?

La mise en place d’un périmètre d’identité résilient nécessite une planification administrative rigoureuse. OAG offre des contrôles granulaires et localisés afin que les politiques de sécurité restent intactes, même en l'absence de télémétrie cloud.

Conception de politique d’authentification déconnectée

Les administrateurs peuvent définir des règles spécifiques pour les scénarios hors ligne. Par exemple, une entreprise peut souhaiter limiter l’accès hors ligne au personnel d’urgence à privilèges ou prévoir un recours à des moyens d’authentification alternatifs.

Configurer des politiques d’authentification déconnectée dans Okta Access Gateway

Orchestration personnalisée de la marque

En cas d’incident sur le WAN ou dans le cloud, la confusion des utilisateurs représente un risque opérationnel majeur. OAG permet aux administrateurs de personnaliser l’expérience hors connexion afin d’alerter clairement les utilisateurs sur la modification de l’environnement :

• Branding distinctif : Conserver des logos de marque personnalisés et des palettes de couleurs opérationnelles spécifiques.
• Avertissements contextuels : Afficher des indicateurs dédiés à destination des utilisateurs, comme une bannière localisée : "Déconnecté du cloud : certaines options peuvent être limitées." Cet ajout simple contribue à limiter la panique, à réduire le volume de tickets adressés au support et à garantir que les collaborateurs respectent les protocoles métier définis pour les situations hors ligne.

Seuils de basculement automatique et de reprise

Pour éviter le « flapping », c’est-à-dire lorsqu’une connexion Internet très instable amène OAG à passer rapidement du mode en ligne au mode hors ligne, OAG utilise une détection d’état à double seuil :

• Intervalle de vérification de l’organisation : Fréquence à laquelle OAG vérifie la disponibilité du tenant cloud (par exemple, toutes les 60 secondes).
• Seuil de bascule : Nombre de vérifications consécutives échouées nécessaires pour activer le mode déconnecté (par exemple, 2 vérifications).
• Seuil de rétablissement : Nombre de vérifications consécutives réussies nécessaires pour repasser en mode en ligne (par exemple, 4 vérifications). Ce paramètre de reprise prudent garantit que le lien WAN est parfaitement stable avant de rediriger les charges d’authentification vers le cloud.

La résilience est une stratégie, pas une fonctionnalité

À mesure que les organisations renforcent l’intégration du cloud, le risque de défailllance de tiers augmente de façon exponentielle. La véritable continuité opérationnelle ne peut être atteinte en se reposant uniquement sur les accords de niveau de service (SLA) ou en partant du principe que les réseaux cloud sont infaillibles.

Pour bâtir une entreprise résiliente de premier plan, les cadres dirigeants doivent prévoir l’échec dès la conception. L’accès hors ligne doit être envisagé non comme une option secondaire, mais comme une stratégie d’architecture essentielle. En adoptant des modèles de plateforme Edge, en définissant des limites strictes en fonction de l’impact métier et en s’appuyant sur des technologies telles que le service d’authentification locale Okta, l’Enterprise moderne peut franchir sereinement les frontières du cloud, tout en veillant à ce que, même en cas d’interruption mondiale, son activité continue d’avancer.

Prêt à sécuriser votre périmètre cloud hybride ?

N’attendez pas la prochaine panne du WAN pour tester vos plans de reprise après incident. Télécharger notre fiche produit Okta Access Gateway pour découvrir comment sécuriser l’accès à vos applications on-premise et protéger votre cloud hybride sans modifier votre code existant.