La redécouverte de la sécurité de l'information
Séparer l'identité et l'accès
Il est frappant de voir le nombre de fois où nous entendons parler d'incidents de sécurité et de fuites de données, en particulier dans les systèmes d'information anciens (voire désuets). En ce qui me concerne, le problème n'est pas tant que ces systèmes sont défectueux, mais plutôt que le pouvoir de décision en matière d'accès est très souvent mal attribué. Bien sûr, cela remonte à très loin, lorsque les départements TIC ont développé les systèmes. Mais cela ne signifie pas que cela doit rester ainsi. Au contraire, il faut que le niveau de gestion (le 'business') ait à nouveau sont mot à dire. Et pour ça, il faudra peut-être emprunter d'autres voies.
pas évolutif
Dans le passé, un système était construit pour gérer des données: une personne recevait un compte pour utiliser ce système et un administrateur attribuait des droits à cet utilisateur. Cela a conduit à une énorme fragmentation des comptes dans différents systèmes pour pouvoir réaliser les processus. Aujourd'hui, nous faisons les choses différemment. Nous achetons de nouveaux services basés sur le cloud et donnons aux gens l'accès à tous ces services et données avec un seul compte Azure via une authentification unique.
Le 'qui' n'est pas évolutif
Et pourtant, tout va mal. Nous nous sommes peut-être débarrassés de la gestion des comptes et des mots de passe, mais la question de l'accès n'est toujours pas résolue. La raison en est que nous pensons encore en termes de personnes, de systèmes et de services. Nous achetons un système ou un service pour aider nos employés dans nos processus. Mais ce n'est plus extensible. Essayez d'accorder un accès à des partenaires commerciaux, des clients et des fournisseurs. La tentation est grande de procéder de manière traditionnelle, de sécuriser nos informations de manière traditionnelle. La gestion des accès du point de vue des comptes et des systèmes n'est pas évolutive.
SÉCURIté DE l'INFORMATION
Cela doit changer. Nous ne devons plus penser en termes de cadres traditionnels, mais en termes de processus et de données traitées. Nous ne devons plus penser à 'qui' peut avoir accès aux processus et aux données (le 'qui' n'est pas évolutif), mais au pourquoi ou aux conditions dans lesquelles quelqu'un doit avoir accès pour pouvoir utiliser les informations sécurisées. Cela nous amène au cœur de la sécurité de l'information: c'est l'information que nous devons sécuriser, pas les utilisateurs. Sur quelle base une personne est-elle autorisée à utiliser un processus ou un élément d'information?
Ça peut être n'importe quoi. Il suffit de penser aux compétences des utilisateurs (junior ou senior), au niveau de fiabilité de la personne (par exemple, provenant d'un partenaire fiable, avec une authentification multifactorielle), aux règles concernant les conflits d'intérêts (quelqu'un n'est pas autorisé à traiter ses propres données d'objet, par exemple sa propre déclaration) ou à un 'key control' tel que la séparation des fonctions (si quelqu'un a effectué la tâche 3, cette personne ne peut pas également traiter la tâche 4).
Mais il ne s'agit pas de savoir qui vous êtes, quel est votre rôle, quel est votre profil, ce que vous êtes autorisé à faire. Il s'agit de savoir pourquoi vous seriez autorisé à faire ça. C'est un questionnement inverse. Bien sûr, nous devons toujours savoir qui a fait quelque chose, mais il ne s'agit là que de journalisation et de surveillance standard. Nous connaissons déjà ça.
POLITIQUE D'ACCÈS
Cependant, la plupart des systèmes traditionnels ne sont pas vraiment faits pour cela. Il y a plus de goulots d'étranglement que de fuites de données résultant de facilités d'accès maladroites. A terme, nous devrons revenir à la sécurité de l'information, précisément parce que nous ne connaissons peut-être pas nous-mêmes l'utilisateur. Et ce moment arrive plus tôt qu'on ne croit: il suffit de penser au déblocage d'API et à la communication entre machines. Pensez à une architecture Zero Trust. Dans ces environnements, il n'y a plus de comptes, il n'y a que des accès.
Accorder l'accès sur base d'autres caractéristiques que les noms d'utilisateur et les rôles
Cela signifie que nous devons séparer l'identité et l'accès. Et cela signifie que nous devons accorder l'accès sur la base de politiques d'accès. En utilisant d'autres caractéristiques que les noms d'utilisateur et les rôles. L'idée est donc la suivante: Attribute-Based Access Control et Policy-Based Access Control au lieu de Role-Based Access Control.
Nouveaux points de départ
Ce ne sera pas une transition facile. Cela exige une nouvelle vision et une nouvelle stratégie, non seulement pour l'utilisation des systèmes, mais aussi pour le développement et l'achat de nouveaux systèmes. Il faut appliquer de nouveaux principes. La nouvelle exigence la plus importante est qu'à l'avenir, l'accès aux informations sera garanti par des politiques d'accès et non plus par les comptes et rôles traditionnels.
A propos de l'auteur
André Koot est consultant principal IAM et cofondateur de SonicBee.
Il a 25 ans d'expérience dans le domaine de la cybersécurité, avec un accent particulier sur la gestion des identités et des accès (IAM) au cours des 20 dernières années. C'est un expert de premier plan reconnu internationalement dans ce domaine.
Koot contribue activement au domaine de l'IAM, notamment en tant que membre du conseil d'administration de la Cloud Security Alliance NL Chapter, membre du comité IDpro et membre du conseil consultatif Identity.Next.
