Cela fait des années que les entreprises préparent leur plan de continuité d’activité face à une pandémie. Cela a débuté en 2009 avec la Grippe A (H1N1) lorsque le gouvernement incitait les sociétés à mettre en place un Plan de Continuité d’Activité Pandémie.
Outre l’achat des équipements de protection (masque, blouse, …) pour le personnel, les entreprises doivent se préparer au télétravail en ouvrant leur réseau informatique vers l’extérieur. Si le VPN est la solution généralement retenue, le lancement du plan de continuité ne s’est pas déroulé sans accroc…
Dans le cadre du plan de continuité d’activité en cas de pandémie, il était prévu que les collaborateurs se connectent au réseau de l’entreprise à travers un VPN. Ainsi, ils pourraient accéder à leurs outils et applications habituelles depuis leur domicile.
Mais pour cet usage, le VPN doit répondre aux exigences suivantes :
Les entreprises se sont tournées vers les grands constructeurs (Cisco Anyconnect, Juniper Pulse, Checkpoint Remote Access, …) pour acquérir le matériel et les licences nécessaires. En cas d'activation du plan de continuité, l’entreprise serait prête pour démarrer le VPN et ouvrir les flux réseau nécessaires sur les firewalls.
Dès le lancement du plan de continuité, les premiers problèmes ne tardent pas à arriver !
Jour 1
Pour se préparer avant le confinement, les employés doivent s’inscrire sur le portail du VPN, installer le logiciel et le configurer correctement. Noyés dans un jargon technique incompréhensible et perdus dans une interface déroutante, les employés n’ont d’autres choix que de solliciter le service informatique qui se retrouve vite débordé.
Le service informatique se trouve ensuite confronté à de nombreux problèmes de compatibilités. Les employés n’ayant pas tous un ordinateur portable fourni par l’entreprise, ils utilisent leur ordinateur personnel sous Windows 7/8/10, MacOS et même parfois Linux. Les techniciens doivent trouver les parades pour installer le client VPN, sous la forme d’un fichier “.msi”, sur MacOS ou encore trouver une alternative à Internet Explorer, seul navigateur compatible avec le portail du VPN.
Le support informatique fait tout ce qu’il peut pour installer les clients VPN sur l’ensemble des ordinateurs. Mais rien à faire, cela ne fonctionne pas sous la dernière version de MacOS. Après investigation auprès du constructeur, le support de la dernière version de MacOS nécessite la mise à jour du VPN. Malheureusement, l’entreprise n’a pas fait de mise à jour depuis 3 ans et ce n’est pas pendant la crise qu’il faut procéder à la mise à jour. Par conséquent, le service informatique remplace les Mac trop récents par un vieil ordinateur sous Windows 7.
Quelques heures plus tard, le service informatique ne peut plus créer de comptes utilisateurs sur le VPN car il n’y a plus de licence disponible. Le plan de continuité prenait en compte uniquement les employés sans tenir compte des prestataires. L’augmentation du nombre de licences n’étant pas économiquement envisageable, il faut donc sélectionner les personnes autorisées à se connecter au VPN.
Jour 2
Le lendemain, les utilisateurs constatent des déconnexions intempestives du VPN. Après investigation, il s’avère que la licence limite le nombre maximum d’utilisateurs simultanés. Ainsi, quand un utilisateur se connecte, un autre est déconnecté. Il est urgent de solliciter le constructeur pour débloquer cette limitation.
Jour 3
Une fois que toutes les personnes autorisées ont pu se connecter au VPN, elles peuvent alors lancer les outils collaboratifs. Malheureusement, la visioconférence (Microsoft Teams, Google Meet, Zoom, …) ne fonctionne pas correctement : la vidéo est de mauvaise qualité et le son saccade ! L’origine du problème est que le client VPN fait passer tous les flux à travers le VPN et sature ainsi la connexion internet de l’entreprise.
Pour y remédier, l’utilisateur doit se déconnecter du VPN pour accéder directement aux outils disponibles sur internet et ainsi libérer la bande passante sur le VPN. Pour les plus confirmés, il suffit en réalité de modifier les règles de routage.
Après le premier week-end
Lorsque tout le monde reprend le (télé)travail le lundi matin, c’est la catastrophe ! Les ordinateurs encore dans les locaux de l’entreprise se sont mis en veille.
En fait, il s’avère que les employés se connectent à distance sur leurs ordinateurs. Cela est indispensable pour utiliser les logiciels installés (Outlook, Lotus Notes ou un CRM en client lourd) ou bien pour accéder à des applications non accessibles via le VPN.
Il faut envoyer un technicien dans les locaux pour allumer les ordinateurs et modifier la configuration de mise en veille pour que cela ne se reproduise pas.
Dans les conditions que nous venons de décrire, il est certain que le télétravail soit fastidieux et peu efficace. La lenteur du VPN fait que les applications métier tombent en “timeout”, notamment lorsque l’utilisateur télécharge un document. Et le temps de latence induit par le RDP rend la frappe au clavier épouvantable.
Avec ces désagréments, il n’est pas étonnant que les employés utilisent des moyens alternatifs et non autorisés par l’entreprise (slack, Google drive, github, …). Quant aux développeurs, ils sont tentés de créer un environnement de développement parallèle dans le cloud, bien plus facile d’accès.
Mais pendant que les employés travaillent tant bien que mal avec le VPN, les groupes de hackers s’attaquent aux nouvelles cibles : les serveurs VPN. Ils sont particulièrement vulnérables (patch de sécurité non appliqué, configuration hâtive, …) et les groupes de hackers n’hésitent pas à mettre les moyens pour trouver de nouvelles vulnérabilités (0day). Après avoir compromis le serveur VPN, les hackers s’infiltrent dans le réseau de l’entreprise ou sur les ordinateurs des utilisateurs.
Finalement, le VPN n’est probablement pas le meilleur choix technique pour permettre le télétravail en toute sécurité. Il faudra trouver une solution plus souple et conserver le VPN pour interconnecter deux entités, par exemple, une entreprise avec un partenaire.
Et si finalement nous devions changer notre façon de concevoir la sécurité ?
Depuis des années nous concevons la sécurité des entreprises comme des châteaux forts en formant un périmètre de sécurité autour de l’entreprise. Et nous tentons désespérément de maintenir ce périmètre de sécurité qui s'estompe au fil du temps.
D’une part, les employés travaillent en dehors du périmètre de sécurité, que ce soit en clientèle, en déplacement ou à la maison.
D'autre part, le périmètre de sécurité est compromis par des équipements introduits dans l’entreprise. Il y a les téléphones portables des employés (BYOD), les ordinateurs des visiteurs (Wifi Guest) et tous les équipements connectés nécessaires au fonctionnement du bâtiment (caméra de vidéosurveillance, climatisation, …).
C’est pourquoi Google a conçu le modèle Beyond Corp. Basé sur les concepts de Zero Trust, ce modèle de sécurité n’accorde pas plus de confiance au réseau interne qu’au réseau externe. Ainsi, que l’employé soit au bureau ou à son domicile, il accède aux applications de l’entreprise de la même façon.
L’architecture simplifiée de ce modèle de sécurité est la suivante:
Google Cloud Platform propose tous les composants nécessaires pour implémenter le modèle de sécurité BeyondCorp (Identity Aware Proxy et Context Aware Access).
Pour les autres fournisseurs de cloud (AWS ou Azure), il faut combiner certains produits pour implémenter une telle architecture. Pour une implémentation open-source, il est possible d’utiliser des Access Proxy, également appelés “gatekeeper” (exemple: keycloak Gatekeeper ou oathkeeper).
Ainsi, le modèle de sécurité Beyond Corp permet aux employés d’accéder, facilement et en toute sécurité, aux applications de l’entreprise. Et ce, qu’ils soient au bureau, en déplacement ou à leur domicile.
Il ne faut pas envisager Beyond Corp comme un complément de sécurité, il faut qu’il remplace intégralement le modèle de sécurité traditionnel. S’il présente beaucoup d’avantages, notamment celui d’être plus compatible au télétravail, il demandera une vraie adaptation du système d’information.
Et si préparer le modèle de sécurité du futur, dès maintenant, devenait un investissement essentiel pour l’ensemble du système d’information ?