La migration d’un SI client vers le cloud public

La réussite d’un tel projet passe impérativement par une solution technique offrant une richesse de fonctionnalités pour répondre aux différents use cases qui devront être traités.

Pour être pérenne, l’architecture de sécurité doit protéger le système d’information (SI) tout en restant la plus invisible et la plus indolore. Ainsi, elle garantit une meilleure expérience utilisateur et facilite le quotidien des administrateurs. Elle doit aussi offrir une grande palette de fonctionnalités de sécurité indispensables au SI. Cette dernière doit être construite autour d’un nombre réduit de technologies qui s’articulent parfaitement ensemble.

Enfin, cette architecture doit être pensée dans un contexte de déploiement par palier, permettant, si nécessaire, d’adjoindre d’autres technologies pour répondre à des besoins très précis. Elle présente un cœur d’architecture qui offre un très bon compromis entre les différents enjeux d’un tel projet : rationalisation, administration simplifiée, expérience utilisateur, nombre de use cases supportés… Des options peuvent être activées ou non en fonction des priorités. Cette architecture optimisée présente aussi une possibilité de déploiement facilitée et, ainsi, un fort potentiel de mise en œuvre efficace et rapide.

Pour faciliter la transition de la migration des applications vers le cloud, nous recommandons un modèle hybride, basé sur une architecture avec trois niveaux complémentaires :

• une partie dite « on premise » pour raccorder les sites distants aux applications et sécuriser les datacenters « legacy » le temps de la migration ;
• une architecture pour sécuriser l’environnement IaaS (Infrastructure as a Service) ainsi que les applications migrées dans le cloud;
• un service SaaS (Software as a Service) pour porter un maximum de fonctionnalités de sécurité dans le cloud afin de bénéficier de ses avantages en termes d’évolutivité et de maîtrise opérationnelle.

A titre d’exemple, pour la sécurisation des flux sortants des utilisateurs en mobilité, les utilisateurs peuvent se connecter au cloud puis ensuite être redirigés vers  une instance firewall dans le IaaS pour accéder à des ressources hébergées dans le cloud public.

Autre illustration, pour la sécurisation des flux entrants, l’instance firewall dans le IaaS peut être protégée par la sécurité SaaS contre les attaques ciblées DDoS (Distributed Denial of Service) sur les sites exposés. En cas d’attaque DDoS volumétrique, la plateforme intermédiaire de sécurité dans le SaaS va absorber l’ensemble de l’attaque et ne laisser passer que le flux légitime, protégeant donc le lien Internet et l’application. Ce cas d’usage est impossible à traiter avec une simple VM (machine virtuelle) dans le cloud et sans plateforme intermédiaire.

Pour la sécurisation de l’infrastructure hébergée dans le cloud public (Amazon Web Services, Microsoft Azure, Google Cloud Plateform, IBM…), étant donné qu’il demeure difficile de prévoir à l’avance la cadence et l’éligibilité de l’ensemble des services applicatifs, nous préconisons trois niveaux de sécurité permettant d’adresser différents cas d’usage.

La sécurité « essentielle »

• implémentation d’une instance firewall dans le IaaS permettant d’adresser les fonctionnalités suivantes : IPS (Intrusion Prevention System) / AV (anti-virus) / URL Filtering / déchiffrement SSL / Sandbox ;
• implémentation d’une instance reverse proxy dans le IaaS permettant d’adresser les fonctionnalités suivantes : reverse proxyavec réécriture URL simple / déchiffrement SSL / filtrage par réputation d’IP URL malveillante.

La sécurité « avancée ». Elle comprend la sécurité essentielle, à laquelle nous ajoutons :

• le SSO (Single Sign On),
• l’authentification de l’utilisateur,
• la réécriture URL complexe.

La sécurité « totale ». Elle inclut la sécurité avancée, à laquelle nous ajoutons :

• le WAF (Web Application Firewall),
• le DDoS applicatif.

Le choix du niveau de sécurité à mettre en œuvre est à la discrétion du client, en fonction de contraintes qui lui sont propres, qu’elles soient géographiques, liées au planning ou à la criticité des applications notamment.

Pour sécuriser les applications web, non-web et métier, nous recommandons la mise en place d’une solution qui offre une plateforme complète de sécurité pour couvrir un grand nombre de cas d’usage (il ne faut cependant pas multiplier les technologies).

Il est souhaitable que cette solution ait un moteur d’inspection unique, notamment pour adresser, avec une règle de flux, l’ensemble des briques de sécurité.

Un point essentiel de la solution est la reconnaissance efficace de la plupart des applications du marché qui permet d’identifier les usages des utilisateurs afin de mieux les protéger.

Le routage et le cloisonnement des flux sont optimisés avec l’appui des routeurs virtuels, les instances de firewall, et la mise en place de notions de zone de sécurité. Le support du protocole SAML (Security Assertion Markup Language) permet de simplifier l’authentification des applications web.

Pour faciliter l’intégration avec l’écosystème existant, l’ouverture des API offre la possibilité de fluidifier les échanges entre les solutions de sécurité. Le contrôle de posture du poste de travail doit être transparent pour l’utilisateur, sans nécessiter de monter un tunnel IPSEC (solution de Remote Access) ni d’implémenter des solutions intrusives comme le NAC (Network Access Control).

Les applications internes migrent vers un environnement public, comment maintenir le niveau de sécurité souhaité ?

L’externalisation du SI augmente naturellement les échanges vers l’extérieur. La solution doit répondre à un maximum de critères techniques et surtout avoir très peu d’impact sur l’architecture déjà en place. Une consolidation de l’ensemble des politiques de sécurité provenant de l’interne ou de l’externe (contrôle réseau, routage des flux, filtrage d’URL, contrôle de conformité, profiling…), mais aussi le routage des flux au sein d’une même console d’administration, sont fortement recommandés pour être plus efficace dans l’ouverture des flux vers Internet.

La solution doit être capable de traiter des flux web autres que http/https et FTP (File Transfert Protocol). L’expérience utilisateur peut ainsi être améliorée et maîtrisée, quelle que soit la localisation (situation de mobilité ou non) pour permettre la connexion des postes utilisateurs en leur appliquant une politique de sécurité adaptée à leur niveau de risque.

Il faut également prendre en compte les exigences des applications SaaS qui ne recommandent pas la proxification, l’authentification et l’analyse des flux. Afin d’adresser les cas d’usages pour des postes non maîtrisés ou sans agent, le portail captif est nécessaire pour sécuriser les réseaux LAN/WAN ou WiFi. L’utilisation et le maintien du fichier proxy.pac pourra, sur le moyen et le long terme, devenir optionnel.

La qualité de l’UX et de la sécurité en mobilité est souvent remise en question quand un utilisateur doit accéder simultanément à des applications privées en VPN et sur Internet. Comment faire ?

L’utilisation d’une solution SaaS publique (firewall cloud) permet d’appliquer les mêmes fonctionnalités de sécurité que celles présentes sur un firewall « on premise ». Cette approche purement SaaS filtre toutes les demandes d’accès utilisateurs à Internet  et offre la possibilité de monter des tunnels site à site (SaaS vers les datacenters privés)  pour accéder à des applications hébergées dans le SI (qui n’ont pas pu être migrées dans le cloud).

Les utilisateurs en situation de mobilité sont donc protégés par cette solution SaaS sans passer par le SI. Cela permet donc d’éviter l’utilisation du split tunneling souvent vecteur de propagation de malwares en créant, depuis Internet, un pont sur le poste de travail pour accéder au réseau interne de l’entreprise. Les fonctionnalités de sécurité proposées, dites « filtrage réseaux », sont plus riches que celles portées par une solution de type proxy SaaS.

La simplification de la sécurité avec des règles de sécurité consolidées, tout en maintenant le niveau de sécurité historiquement en place permet aux équipes du client d’être plus efficaces au quotidien, et ce, en réduisant le temps d’investigation et de traitement des incidents. L’expérience utilisateur est améliorée avec un accès Internet direct sans passer par le site central en respectant les contraintes des utilisateurs et des applications.

L’évolutivité et la migration accélérée de la plateforme ont été prévues à cet effet, en grande partie par ajout de licences utilisateur ou de bande passante. Cela permet d’être réactif suite à d’éventuels nouveaux besoins. Le niveau de sécurité a été respecté dans les règles de l’art tout en restant conforme aux exigences des applications métier hébergées dans le cloud.

A noter que toutes ces actions ont été effectuées sans aucune dégradation de service rendu aux utilisateurs mais aussi sans diminution du niveau de sécurité.