Conception de la gestion des utilisateurs pour la machine

Par Aviad Mizrachi, InfoMonde |

La technologie émergente disséquée par les technologues

Si un utilisateur manque de traits humains et n'a pas beaucoup de personnalité, il peut y avoir une bonne raison à cela. L'utilisateur peut être une machine.

Aujourd'hui, plus de 90 % du trafic Internet se fait entre machines. En réalité, les machines qui consomment votre application B2B SaaS sont également des utilisateurs, juste un autre type d'utilisateur. C'est pourquoi chaque application en ligne et SaaS doit aujourd'hui inclure des pratiques et des politiques de gestion des utilisateurs bien pensées, spécialement conçues pour gérer les différents défis et exigences des interactions machine à machine (M2M).

Sur la base d'années d'expérience à aider les entreprises B2B SaaS à gérer les interactions M2M, j'ai élaboré un guide rapide avec les meilleures pratiques pour une gestion des utilisateurs de machine à machine efficace, efficace et sécurisée. Plongeons dedans.

Le contexte peut être critique dans la gestion des utilisateurs humains, mais il est encore plus critique pour les machines car les utilisateurs de machines offrent beaucoup moins d'informations sur leur statut, leur situation et leur intention. Souvent, les utilisateurs de machines n'accèdent qu'à un seul service ou à un petit nombre de services, tandis que les utilisateurs humains accèdent à beaucoup plus.

Les interactions de machine à machine ne contiennent pas d'indices utiles tels que l'agent de navigateur, l'adresse MAC ou NIC ou les données de géolocalisation. Ils sont plus susceptibles d'être un appel API dans un protocole couramment utilisé avec un minimum de caractéristiques d'identification. Le contexte entourant les demandes de service effectuées par un utilisateur de machine doit déterminer la manière dont les stratégies sont appliquées et la gestion des utilisateurs est conçue.

Pour la gestion des utilisateurs M2M, chaque service doit savoir comment il peut communiquer avec d'autres services et avec quels services il doit communiquer. Tous les services doivent savoir comment ils communiquent avec un autre service et les services clés auxquels ils doivent être autorisés à accéder. C'est en partie ce que les passerelles API et les maillages de services peuvent offrir, mais aucun n'a une approche centrée sur l'utilisateur (même pour les utilisateurs M2M).

Pour les utilisateurs humains d'aujourd'hui, MFA est un élément essentiel du processus de validation de la sécurité. Pour les utilisateurs de machines, MFA n'est pas une option. Dans le même temps, les transactions M2M ont tendance à fonctionner en quelques millisecondes, car les machines peuvent interagir à une vitesse beaucoup plus rapide que les humains. Cela crée une nouvelle zone de surface d'attaque que de nombreux cybercriminels tentent désormais activement d'exploiter via des attaques d'API. Pour les équipes SecDevOps exécutant des processus de gestion des utilisateurs contre les interactions M2M, cela signifie qu'une attention beaucoup plus stricte doit être accordée à d'autres mécanismes de sécurité tels que la limitation des adresses IP, la limitation du taux de demandes, la rotation des certificats ou des clés et, idéalement, les politiques générées par l'homme ou par la machine. qui reconnaissent les modèles d'utilisation anormaux.

Qu'une demande provienne d'une machine interne ou d'un utilisateur externe doit déclencher des considérations de sécurité très différentes. Si une demande est interne, provenant d'un cluster Kubernetes d'un service à un autre, l'authentification est appliquée en interne et généralement avec une touche plus légère. Par exemple, les maillages de services sont utilisés pour définir des politiques sur les services auxquels un service interne donné peut se connecter. En réalité, de nombreuses organisations n'authentifient toujours pas les interactions internes de machine à machine, mais les RSSI et les équipes de gestion des risques s'efforcent de mettre en œuvre l'authentification de base partout.

À ce jour, de nombreuses opérations de plate-forme et équipes SecDevOps utilisent l'authentification naïve pour la sécurité interne, c'est-à-dire les secrets partagés. Cependant, l'authentification naïve nécessite un processus solide pour remplacer facilement les secrets qui ont été violés ou exposés d'une manière ou d'une autre. Sans ce processus d'échange de secrets, une organisation risque des temps d'arrêt pendant que de nouveaux secrets sont créés et partagés. À grande échelle, les modifications apportées aux secrets qui doivent être synchronisés entre des paires ou des trios d'utilisateurs de machines représentent beaucoup de travail. Ainsi, même pour la communication M2M interne, il existe des défis technologiques.

Pour les communications M2M externes et la gestion des utilisateurs de machines, les choses se compliquent beaucoup. Le partage de secret est une sécurité insuffisante. Pour le démontrer, considérons l'exemple suivant. Disons que nous avons deux services : un service utilisateur et un service de messagerie. Nous voulons envoyer un e-mail à un utilisateur. Tous les utilisateurs n'ont pas droit aux e-mails. Ainsi, pour gérer correctement l'utilisateur, l'application doit savoir quel utilisateur est autorisé à envoyer un e-mail et quel e-mail doit être indiqué pour les messages envoyés à cet utilisateur. Les secrets s'effondrent rapidement dans ce monde.

Ce cas d'utilisation souligne également pourquoi les jetons Web M2M JSON (JWT) sont préférables aux services de communication M2M génériques. Le service de gestion des utilisateurs doit alors générer un jeton pour un utilisateur spécifique ou une organisation spécifique. Le jeton peut être révoqué ou configuré pour nécessiter des renouvellements à certains intervalles.

Une politique de cycle de vie des jetons et un système opérationnel bien conçus permettent aux services de sécurité et de gestion des utilisateurs de révoquer rapidement l'accès ou de faire pivoter les clés sans interruption opérationnelle. La politique est automatiquement appliquée via des listes de révocation ou de renouvellement de certificats. Si les renouvellements se font dans des délais relativement courts, il est alors possible d'ajuster la gestion des utilisateurs pour fournir une confiance proche du zéro aux utilisateurs M2M. Les jetons JWT peuvent contenir plusieurs attributs, ils sont donc particulièrement utiles pour encoder le contexte.

Une deuxième façon pour les organisations de gérer l'authentification externe consiste à utiliser le jeton d'accès, où un utilisateur reçoit une chaîne de valeur unique. Voici comment fonctionne un jeton d'accès :

Un jeton d'accès est très bon pour les transactions simples mais peut tomber en panne dans des scénarios plus compliqués, créant un point de défaillance unique. Par exemple, si pour une raison quelconque le jeton d'accès n'est pas validé, il n'y a pas de recours facile ni d'autre mécanisme pour évaluer la confiance. Fonctionnant sur une architecture de microservices, cela implique un flux plus compliqué et plus difficile à gérer. Un utilisateur de machine aurait besoin d'une validation instantanée vers un serveur de validation et une voie de service distincts. Avec les JWT, tout ce que le service doit savoir, c'est si l'utilisateur dispose d'un JWT valide, qui stocke tout le contexte d'accès. Il n'est pas nécessaire d'exécuter un processus séparé pour valider cela.

Un troisième chemin est celui des informations d'identification du client. Il s'agit d'un ensemble d'informations d'identification fournies par une application, telles qu'un ID client et un secret, qui sont utilisées pour authentifier l'application et autoriser l'accès à un serveur de ressources. Les informations d'identification des clients intègrent souvent des JWT et ont l'avantage d'être plus sécurisées car elles nécessitent deux pièces d'identité. Et bien que les informations d'identification du client puissent être moins conviviales, cela pose moins de problème lorsque l'utilisateur n'est pas un humain.

Cependant, avec les informations d'identification du client, le système doit être conçu avec soin pour permettre une atténuation rapide des pannes et une réduction des goulots d'étranglement. Cela peut être particulièrement difficile lorsque vous comptez sur d'autres systèmes distribués, tels que Google ou OAuth, ou un certificat cloud tiers ou une autorité de jeton. Dans ce scénario, une organisation peut s'appuyer sur un JWT qu'elle ne génère ni ne contrôle.

Un juste milieu entre les informations d'identification du client et les contrôles d'accès peut être Mutual TLS (mTLS). mTLS garantit que les parties à chaque extrémité d'une connexion réseau sont bien celles qu'elles prétendent être en vérifiant qu'elles disposent toutes les deux de la bonne clé privée. Cela superpose des mécanismes de validation de confiance supplémentaires au point de prise de contact. Certains maillages de services, proxys inverses et passerelles API appliquent mTLS par défaut, mais la synchronisation de mTLS sur l'ensemble de votre pile d'infrastructure nécessite une véritable conception du système et une réflexion approfondie.

Alors que le nombre de services et de microservices continue d'augmenter et que de plus en plus d'applications sont architecturées au-dessus des API, le développement d'une stratégie et d'une pratique de gestion des utilisateurs solides pour les interactions M2M devient critique. Ça signifie:

N'oubliez pas que les machines sont aussi des utilisateurs. Vous devrez les traiter comme des utilisateurs pour vous assurer que les services qu'ils utilisent sont disponibles, rapides, évolutifs et sécurisés.

Aviad Mizrachi est CTO et co-fondateur de Frontegg.

—

Le New Tech Forum offre un lieu pour explorer et discuter des technologies d'entreprise émergentes avec une profondeur et une ampleur sans précédent. La sélection est subjective, basée sur notre sélection des technologies que nous pensons importantes et les plus intéressantes pour les lecteurs d'InfoWorld. InfoWorld n'accepte pas les supports marketing pour publication et se réserve le droit de modifier tout le contenu contribué. Envoyez toutes les demandes à [email protected].

Lisez ensuite ceci :

Blog