Un responsable de la sécurité informatique chez un de nos grands clients nous a récemment fait part d’une réflexion qui nous a semblé particulièrement juste.
« Désormais, le Cloud est devenu le data center. Internet est devenu le réseau interne. L’identité est devenue le périmètre de sécurité, et tout terminal est devenu un terminal professionnel. »
Développons chacune de ces quatre affirmations pour en comprendre les implications.
#1 Le Cloud est devenu le data center
Sur ce premier point deux choses sautent immédiatement aux yeux. La première est qu’à moins de devoir satisfaire à des exigences réglementaires spécifiques, ou d’avoir une totale confiance dans la qualité et l’intérêt financier d’une solution matérielle et logicielle hébergée en interne, les offres cloud SaaS, PaaS ou IaaS actuelles sont devenues un choix évident pour les entreprises.
La seconde, encore plus importante, est qu’il n’est plus nécessaire de savoir où les services et applications des entreprises sont hébergées et qui les fait fonctionner. Peu importe que l’accès aux applications s’effectue via une instance MySQL en local ou MariaDB, une instance AWS Aurora MySQL, ou une base de données Azure pour MySQL.
#2 Internet est devenu le réseau
Tout devrait désormais être connecté et accessible. Les utilisateurs ne devraient plus avoir besoin d’être présents physiquement sur un site, ou d’utiliser un VPN pour accéder à des applications réservées à l’interne. Le modèle tripartite : Internet, DMZ, et réseau interne sécurisé protégé ne permet pas un accès n’importe où n’importe quand, et ne fonctionne pas bien lorsqu’il s’agit de connecter ensemble des applications et des services fonctionnant dans des environnements hybrides associant data centers internes et de multiples fournisseurs de services cloud.
Faire une confiance aveugle à toute application ou système installé derrière un firewall est aussi une mauvaise habitude. Dans un tel scénario, si une application est compromise, elle peut être utilisée comme base pour attaquer bien d’autres applications et systèmes. C’est exactement ce qui s’est produit lors de récents piratages majeurs.
Donc si l’on ne dispose pas d’un périmètre de défense capable de protéger des applications et ses données, que faire ? La troisième affirmation citée plus haut apporte la solution.
#3 L’identité est devenue le périmètre de sécurité
L’adoption (implicite) d’un environnement « zero trust » doit aujourd’hui s’imposer. Dans ce type d’environnement, tout a une identité propre : les utilisateurs, les applications, les services et les systèmes.
Il s’agit d’environnements incroyablement sécurisés et flexibles, dans lesquels chaque application et service est potentiellement accessible par tout le monde, quel que soit le lieu où ils sont hébergés : sur site, dans un cloud privé ou public.
Cependant, cette flexibilité a un prix. Pour garantir un écosystème sécurisé, plusieurs éléments doivent être mis en place :
Les identités, qu’elles concernent des humains ou des applications, doivent être établies ou validées d’une manière sécurisée. Ceci peut être réalisé via une vérification d’identité, la délivrance sécurisée de certificats, le service d’identité d’Istio, etc. L’objectif est d’être sûr que l’individu ou l’objet est bien ce qu’il prétend être.
L’identité doit être authentifiée en toute sécurité solidement lors de l’exécution. Elle peut être réalisée via une authentification multifacteur (MFA), une authentification par certificat, un OAuth client secret, etc. Dans le cas d’une authentification multifacteur, il convient de s’assurer que le canal de récupération n’est pas identique pour les différents facteurs. En cas de fourniture d’identifiants à des services via devops, les identifiants ne doivent pas être stockés en clair, et l’ensemble du processus de livraison doit être sécurisé.
Les identités ne doivent pas risquer d’être volées ou divulguées. Elles sont généralement volées via des attaques dites de ‘credential stuffing’ au cours desquelles des bots utilisent des listes d’identifiants et mots de passe volés pour trouver et voler des identités. Ceci constitue un risque à prendre au sérieux : rn effet, la plupart des études montrent que ces attaques sont entre 2% et 3% efficaces. Ceci veut dire que si une entreprise possède plus de 50 comptes utilisateur, elle est potentiellement vulnérable.
L’authentification multifacteur peut prévenir des attaques de ‘credential stuffing’, mais n’empêchera pas automatiquement les utilisateurs de divulguer leurs identifiants via des attaques de ‘phishing’. Pour prévenir ce type d’attaques, des formations anti-phishing et l’adoption de la solution d’authentification multifacteur FIDO2 sont recommandées. FIDO2 prévient les attaques de ‘phishing’ en obligeant l’utilisateur à enregistrer au préalable tous les sites authentifiés. Elle n’acceptera ensuite que les demandes d’authentification provenant des sites enregistrés, bloquant ainsi tous les faux sites de ‘phishing’ qui tenteraient de récupérer de récolter vos mots de passe et code à usage unique (OTP) puis de prendre le contrôle de votre session utilisateur.
Un processus explicite d’autorisation d’accès doit intervenir entre deux points d’un système, quels qu’ils soient. Ceci s’applique aux utilisateurs, aux applications et aux services. L’autorisation doit être refusée par défaut sauf dans le cas d’une autorisation explicite stipulant que le demandeur, qu’il s’agisse d’un humain ou d’une application, est autorisé à accéder à ces données, à ce service ou à cette application.
Plutôt que s’appuyer uniquement sur des règles rigides et définies de façon statique, il est préférable de se tourner vers une solution alimentée par du machine learning, plus flexible, afin d’améliorer les processus d’authentification et d’autorisation. Ces solutions améliorent l’expérience utilisateur en supprimant des étapes d’authentification inutiles lorsqu’il existe une réelle certitude que l’utilisateur est bien celui qu’il prétend être. Elles peuvent aussi analyser les schémas d’accès pour détecter des botnets ou des piratages de données et ainsi refuser l’accès dans des cas où des règles statiques n’auraient rien bloqué.
#4 Tout terminal est devenu un terminal professionnel
La quatrième affirmation résulte directement des trois autres.
N’autoriser l’accès aux données et aux applications qu’à partir des terminaux de l’entreprise est un cauchemar en termes de management, et réduit la productivité des employés. Dans une économie 24/7, les employés doivent être capables d’accéder aux informations et applications en tous lieux et à partir de n’importe quel terminal.
Ceci ne veut pas dire que chaque terminal ne doit pas être validé pour s’assurer qu’il n’a pas été piraté. Les entreprises peuvent utiliser des solutions MDM ou CASB pour contrôler la diffusion des données. Pour des cas d’usages aussi bien grand public qu’en entreprise, l’analyse des données peut également aider à détecter des anomalies sur la base de facteurs tels que la géolocalisation et les schémas d’accès. L’objectif primordial est d’établir des processus de contrôle qui permettent aux équipes de sécurité de maîtriser tous les usages BYOD à la fois pour des cas d’utilisation professionnels ou grand public.
Des accès de n’importe où, n’importe quand, n’importe comment
En bref, les entreprises doivent inverser leur façon de penser. Au lieu d’essayer d’enfermer les applications et les données dans des coffres forts sécurisés, elles doivent en autoriser l’accès depuis n’importe où.En adoptant une politique d’accès à n’importe quelles données, en tout lieu et à partir de n’importe quel terminal, ainsi qu’en mettant en place les procédures et les contrôles nécessaires pour en faire une réalité parfaitement sécurisée, les entreprises pourront améliorer le confort de travail de ses employés et accroître leur productivité. Elles pourront aussi disposer d’une infrastructure flexible qui leur permettra de s’adapter facilement à l’évolution rapide de leurs besoins et de leurs choix technologiques sans avoir à reconfigurer leurs systèmes.
.jpg){kind=link}